[18:11:11] --- nico has joined
[18:11:42] --- nico has left: Disconnected
[18:12:09] --- nico has joined
[18:12:49] --- david.black has joined
[18:13:08] --- semery@jis.mit.edu has joined
[18:13:22] --- lha has joined
[18:13:47] <lha> we are staring now
[18:13:56] <nico> Im not at home
[18:14:10] <nico> so no Skype-ing in today
[18:14:11] <david.black> Audiocast is coming through fine
[18:14:15] --- jimsch1 has joined
[18:14:52] <david.black> You need Sam before the meeting ends!
[18:16:03] <nico> what's the agenda?
[18:16:20] <jimsch1> 1. intro
[18:16:21] <jimsch1> 2. review
[18:16:28] <jimsch1> 3. accept comments on lconnection latching
[18:16:29] <nico> if there's stuff I'm not needed for 8 minutes or so I can go home and dial in
[18:16:40] <jimsch1> 4. interaction between btns and nsf
[18:16:52] <jimsch1> first 5 minuts are review of documents
[18:16:59] <david.black> Item 4 is the one that Sam is crucial for.
[18:17:18] <nico> thanks
[18:17:19] <david.black> "nsf" --> "nfs", specifically NFSv4
[18:18:39] <nico> is Dan McDonald in the room?
[18:19:05] <david.black> Don't see him on the participant list.
[18:19:15] <nico> he's the expert on how connection latching works in Solaris
[18:19:28] <nico> physically in the room
[18:19:35] <nico> he's physically at Vancouver
[18:19:44] --- hartmans@jis.mit.edu/owl has joined
[18:20:41] <nico> audio is silent -- is that because everyone is reading the I-D?
[18:20:49] <semery@jis.mit.edu> Yes.
[18:20:53] <jimsch1> yes - you have about 20 minutes
[18:20:56] <nico> excellent
[18:22:19] <nico> hmm, I think the last sentence in the abstract needs to be removed or re-written
[18:22:27] <nico> I missed that in the last update
[18:22:28] --- kdz has joined
[18:22:55] --- bdr has joined
[18:24:29] --- jhutz has joined
[18:24:47] <nico> hold on
[18:24:58] <nico> are we looking at -03 or -04?
[18:25:18] <lha> the last submitted
[18:25:31] <nico> in the I-D tracker that's -03
[18:25:37] <semery@jis.mit.edu> I have 03 in front of me.
[18:27:25] <nico> ah, yes, soon after I submitted -03 I noticed that the abstract needed to be updated
[18:27:31] <nico> and one other minor thing
[18:27:32] --- john.zhao has joined
[18:27:35] <nico> but didn't submit -04
[18:27:41] <jhutz> If an IPsec channel is desired then inbound packets for a given connection MUST NOT be accepted (they MUST be dropped) until the channel is established. It seems to me that the OS may not know this in time, especially on a server, since some clients may use IPsec channels and some may use TLS or something else.
[18:28:13] <jhutz> Also, how does this interact with, say, accepting a TCP connection?
[18:29:18] <nico> described below
[18:30:34] <jhutz> Oh, well, you say you have to treat dropped packets as packet loss, which is reasonable.
[18:30:54] <nico> yes
[18:31:01] <jhutz> but in practice, that's going to make establishing TCP-over-IPsec suck, because you're going to end up having to wait the TCP retransmit time every time.
[18:31:10] <nico> no
[18:31:14] <jhutz> Why not?
[18:31:34] <nico> because you being to establish the latch on the first TCP packet for that connection
[18:31:40] <david.black> Hmm - I see a chicken/egg problem with dropping packets - what happens if the packets go through something like inetd and the channel binding is only established by the server that inetd launches? Dropped packets result in inetd seeing nothing.
[18:31:53] <nico> once you have the latch the only packets you drop are the packets that don't match the latch
[18:32:11] <jhutz> Oh, OK; as long as you can do that on receipt of the first SYN.
[18:32:27] <nico> david: channel binding is out of scope here (but to answer your question, that doesn't happen)
[18:32:34] <nico> jhutz: exactly
[18:32:38] <lha> maybe that should be described better then?
[18:32:48] <nico> is 20 minutes enough?
[18:32:48] --- john.zhao has left: Replaced by new connection
[18:32:48] --- john.zhao has joined
[18:32:50] <jhutz> David, I don't think that's a problem, because it's not establsihing the channel _binding_ that's at issue, but the channel itself; that is, the latching of a ULP connection to IPsec parameters.
[18:32:57] <hartmans@jis.mit.edu/owl> You establish the SA before the first syn. Then, you establish the latch and find the existing sa
[18:33:04] <david.black> Oops, read "connection latch" for "channel binding" in that long comment (my thinko).
[18:33:23] <jhutz> But, how do you deal with the situation where a server wants to accept connections on some port, and leave it entirely up to the client to decide whether it wants to use an ipsec channel or something else?
[18:33:25] <nico> and the channel establishment happens in the IP/IPsec and IKE stacks
[18:33:36] <nico> jhutz: see section 3
[18:33:46] <jhutz> Oh, OK; haven't got that far yet.
[18:33:55] <nico> 3. Optional protection
[18:33:56] <david.black> Sam: I agree the SA has to be established before the first SYN, but I don't see how IPsec puts the latch in place.
[18:34:11] <nico> david: the ULP tells IPsec to do so
[18:34:21] <nico> the ULP, in that case, being TCP
[18:34:36] <david.black> Initiating ULP can tell IPsec, but what if responding ULP is launched on demand by something like inetd?
[18:34:49] --- jlaganie has joined
[18:35:21] <nico> app: "connect(...)"; TCP: "need and SA pair and a latch for this 5-tuple"; IPsec: <IKE exchanges>; TCP: send SYN; ...
[18:35:43] <david.black> Ok, now what about "listen(...)" followed by connection handoff?
[18:35:46] <nico> david: for the responder there is a listener latch
[18:35:54] <nico> much like there is a listener socket
[18:36:04] <nico> created when the listener socket is created
[18:36:06] <hartmans@jis.mit.edu/owl> The latch requirement needs to be set up when the listening socket is created
[18:36:12] <nico> right
[18:36:22] <nico> and that's also where optional protection comes in
[18:36:30] <david.black> Ok, so if inetd wants to play, it has to latch everything it supports? I guess that works.
[18:36:39] <nico> david: yes, exactly
[18:36:43] <hartmans@jis.mit.edu/owl> Unless you are doing optional protection. I wonder if this supports simultaneous open:-)
[18:36:50] <jhutz> I should have brought the jabber laptop for this session
[18:36:58] <nico> sam: it does!
[18:37:16] --- kivinen has joined
[18:37:24] <david.black> Is Love watching jabber?
[18:37:25] <nico> I didn't discuss simulataneous open, but you can see that, as long as the end-points in the simultaneous open are the same, then it works
[18:37:41] <nico> use the mic!
[18:37:52] --- leifj has joined
[18:38:21] <leifj> clean up last-but-1 para in 2 (before 2.1)
[18:38:28] <nico> yes, there are things that I cleaned up a bit in an as yet unsubmitted -04
[18:38:42] <nico> I can post the diffs I have already
[18:38:44] <leifj> Describe what must happen (nor not) when doing the Destroy operations
[18:38:46] --- andrew.daviel has joined
[18:38:59] <jhutz> I'm not sure it does need to be clarified; that could just be my misunderstanding of the existing protocols.
[18:39:10] <jhutz> IPsec is not my area of expertise
[18:39:11] <leifj> those ops are just sitting there
[18:39:20] <hartmans@jis.mit.edu/owl> Yeah, destroy was under described.
[18:39:51] --- stephen.morris has joined
[18:40:19] <hartmans@jis.mit.edu/owl> Has Steve Kent looked at this at all? I'm surprised he is not complaining about lack of a more complete model with explicit transitions.
[18:40:40] <jimsch1> Steve said "I'm not interested"
[18:40:42] <david.black> Would be useful for section 1 to say that for TCP, both connect and listen ends need to latch connection in advance.
[18:40:46] --- andrew.daviel has left
[18:40:50] <nico> I'm not following what Tero is saying
[18:41:00] <nico> he's not coming through clearly inthe audio
[18:41:24] <jimsch1> Do you want him to repeat or e-mail?
[18:41:29] <nico> e-mail
[18:41:42] <nico> is Steve in the room?
[18:41:45] <kivinen> In 2.1 there is text that says you should not have SAs with overlapping traffi cselectors, and you should avoid the situation.
[18:42:11] <jimsch1> physically, not mentally
[18:42:11] <kivinen> I would say we should only disallow such situation if it actually affects the latching, i.e. the SAs have different algorithms or IDs etc.
[18:42:56] <david.black> Tero - what if the two latches have different IDs?
[18:43:03] <kivinen> If you use the overlapping traffic selectors for the QoS reasons (i.e. to make sure that one Qos Parameter set is transferred inside one SA) then those SAs have identical properties.
[18:43:32] <kivinen> If they have different ID or different algorithms, then you need to do something for that, i.e. break latching or disallow creating such.
[18:43:39] <david.black> Ok, that's safe provide that the IDs match, and probably a few other things ...
[18:44:31] <kivinen> Oh, it is actually talking about SAs with different peers with overlapping traffic selectors, I didn't notice the text "different peers" there.
[18:44:31] <david.black> I'm part of the TSV Directorate - does Sam have something specific he wants aside from "review"?
[18:44:44] --- jimsch1 has left
[18:44:57] --- stephen.morris has left
[18:45:10] <nico> if you can't maintain the latch then you must break it
[18:45:18] <leifj> meeting ends
[18:45:18] <nico> and inform the ULP and application
[18:45:22] <kivinen> but I have to say that document needs to be read couple of times before I can really say how it works and understand it...
[18:45:27] --- leifj has left
[18:45:40] <nico> so was Dan not in the room?
[18:45:42] --- kdz has left
[18:46:14] <semery@jis.mit.edu> Love didn't see him.
[18:46:16] <david.black> Nico: Can you ping/draft Dan offline?
[18:46:51] --- jhutz has left
[18:47:12] <nico> trying...
[18:47:19] <nico> obviously it's too late
[18:47:31] <david.black> Email from experts to the list is always timely ...
[18:47:40] <nico> but he could talk to folks in the hallway
[18:49:40] --- andrew.daviel has joined
[18:49:45] <kivinen> Hmm.... Actually checking the 2.1 text with different peers and overlapping traffic selectors, the easy solution is to say that you use decorrelated policy, as then you do not have overlapping traffic selectors.
[18:50:51] <david.black> Not that easy - may have to decorrelate on the fly.
[18:50:53] --- semery@jis.mit.edu has left: Disconnected
[18:52:15] <david.black> Probably better to say that this has to be figured out in advance so that a multi-app traffic selector doesn't happen and a single app selector won't need to be split by decorrelation.
[18:54:13] <kivinen> But this was too short time to read the document, so need to get proper review of it later and send comments to the list...
[18:55:58] --- kivinen has left
[18:57:18] --- david.black has left
[18:57:54] <nico> yes
[18:57:57] <nico> please do
[18:57:58] <hartmans@jis.mit.edu/owl> I thought you could have overlapping SAs which seem like they would overlap even with decorrilated policy in terms of what packets wou/ld be accepted.
[18:58:51] <nico> I believe that's correct
[18:59:37] <nico> that is, requireing decorrelation is not sufficient
[19:00:37] <nico> the IPsec key manager does not today try to exclude the possibility of two SAs existing at the same time with the same TSes but different IDs
[19:00:40] <nico> for example
[19:01:11] <nico> and it doesn't try to exclude the possibility of two SA with the same IDs, overlapping TSs and different algorithms
[19:01:32] <nico> connection latching is an exclusion mechanism for the IPsec key manager
[19:02:10] <nico> in an earlier version I had this exclusion be enforced at child SA creation time, but now I have it enforced only w.r.t. latch mgmt
[19:02:20] <nico> so that we don't modify the IPsec model at all
[19:02:37] <nico> when such conflicts arise the latch manager simply breaks the relevant latch
[19:03:22] --- john.zhao has left: Computer went to sleep
[19:03:32] --- lha has left
[19:05:28] --- nico has left
[19:08:39] --- bdr has left
[19:10:19] --- nico has joined
[19:10:30] --- nico has left
[19:12:07] --- andrew.daviel has left
[19:37:43] --- jlaganie has left
[19:58:54] --- john.zhao has joined
[20:01:05] --- john.zhao has left