[06:41:35] --- guhasaikat has joined
[12:53:37] --- psavola has joined
[12:54:07] --- lars has joined
[12:58:07] --- jishac has joined
[13:06:40] --- wrstuden has joined
[13:07:16] * jishac has fallen victim to jabber scribe :)
[13:07:26] <guhasaikat> /wave
[13:07:35] <jishac> Agenda Bashing
[13:07:41] --- touch has joined
[13:09:58] --- faber has joined
[13:14:23] <jishac> ROOM TOPIC: Updates to TCP-Secure (R. Stewart)
[13:16:21] --- mallman has joined
[13:18:57] <jishac> Joe Touch *ran* to the mic
[13:19:59] <jishac> Last revision that Joe saw only had minor changes, wanted to know where the doc was with the substantial changes
[13:21:04] <jishac> (between 04 and 05)
[13:21:19] --- wrstuden has left
[13:21:20] <lars> http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcpsecure/draft-ietf-tcpm-tcpsecure-05-from-04.diff.html
[13:21:58] <jishac> joes does not think the upcomming 06 is ready for last call unless it addresses some issues
[13:22:25] <jishac> lars: thanks for the link
[13:24:03] <jishac> chairs would like the issues to go to the list (and not just fly between stewart and touch)
[13:24:26] <jishac> also any contribution of text would be appreciated
[13:24:48] <faber> (Lars, is there a similar 03-04 link?)
[13:25:01] <jishac> ROOM TOPIC: TCP SYN Flooding Attacks and Mittigation (W. Eddy)
[13:25:21] <jishac> http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-tcpsecure/
[13:25:28] <jishac> the tools site is handy
[13:28:17] <lars> yes there is
[13:28:40] <faber> s/4/3; s/5/4/?
[13:30:13] <jishac> lars has noted that this has no milestones
[13:31:01] <jishac> mic: all the milestones are out of date, they should just all be updated
[13:31:06] --- mallman has left
[13:31:41] <jishac> chairs: other option is that TCP becomes historic and this is all moot
[13:31:58] <jishac> (as suggested earlier today in tsvarea)
[13:32:18] <jishac> ROOM TOPIC: Revising 2581 (M. Allman)
[13:37:08] <jishac> How to deal with ssthresh on duplicate RTO's for the same packet
[13:37:32] <jishac> M Mathis: How do you RTO for the same packet and get any other acks
[13:37:57] --- shikob has joined
[13:38:07] <jishac> Mark: knows of none
[13:38:10] --- touch has left
[13:39:35] <jishac> M. Mathis: are reall stacks setting from flightsize (doesn't like the whole flightsize notion)
[13:39:55] <jishac> R. Stewart: wanted clarification of how ssthresh could be hammered down further
[13:40:32] <jishac> if your under heavy congestion you will loose _other_ packets and those losses will trigger reductions to cwin/ssthresh
[13:40:53] <jishac> proposal if for the RTO's of the _same_ packet
[13:41:49] <jishac> Missed initiial comments, but Gorry final comment was that the new scheme sounds ok
[13:43:30] <jishac> T Faber: quick fill of a big BDP is not on the slides and should be taken to the list
[13:43:41] <jishac> advantage that needs to be discussed
[13:44:58] <jishac> Mark requests any reasons why this is a bad idea
[13:45:01] <jishac> there are none
[13:45:36] <jishac> ROOM TOPIC: Editorial [Anti-spoof issues] (J. Touch)
[13:45:40] --- mallman has joined
[13:46:17] <jishac> s/editorial/open request/
[13:47:31] <jishac> ROOM TOPIC: NAT Behavioral Requirements for TCP [Part of the "behave" group] (P Matthews)
[13:47:56] --- touch has joined
[13:52:34] <jishac> so the idea is that P2P apps will use a central server to coordinate and let both ends try to initiate
[13:52:51] <jishac> and the 6s lets that happen
[13:53:24] <jishac> F. Baker: Is it configurable... there is an attack here.
[13:53:31] <guhasaikat> requirement is a SHOULD ... NAT can hide the ICMP if it want's to defend against attack
[13:53:48] <jishac> it admits to your presence
[13:54:23] <guhasaikat> security section allows NAT to violate the SHOULD to protect against the attack.
[13:55:56] --- wrstuden has joined
[13:56:13] <jishac> guhasaikat comment is raised and satifies both Baker and Touch's concerns
[13:57:40] <jishac> M Mathis raises issue about the possible ICMP issues (didn't get the main concern though)
[13:58:26] <jishac> J Touch: ICMP should be 'port unreachable' because it is exactly the right message to send
[13:59:26] <jishac> (if there are no port forward records then indeed the NAT has no host port to send the syn to... Touch's comment makes sense)
[14:02:39] <jishac> (isn't the 6s a security problem in terms of resources?)
[14:03:02] <guhasaikat> (draft says if NAT doesn't have resources then it can ICMP rate limit)
[14:03:05] --- rono has joined
[14:03:51] --- fred@ecotroph.net has joined
[14:04:53] <touch> and that rate limit is what 1122 and 1812 say about ICMPs too ;-)
[14:05:22] <jishac> so there was a trade here, of soft errors and the delayed ICMP... and the rooms favor was to the delayed ICMP
[14:06:14] <faber> No hum on that, but no voiced disagreement.
[14:06:22] <jishac> right
[14:06:25] --- sarolaht has joined
[14:08:05] --- mankin has joined
[14:11:41] <jishac> ROOM TOPIC: RDDP: TCP Framing [from rddp WG] (David Black - chair of rddp)
[14:15:10] --- mankin has left
[14:17:44] <jishac> ROOM TOPIC: Combined Fixes for TCP over Dynamic Paths (Wes Eddy)
[14:22:30] --- touch has left
[14:22:34] --- guhasaikat has left
[14:23:46] <jishac> chairs: Clarification, putting up as a work item in this WG?
[14:23:50] <jishac> Wes: Yes
[14:24:27] <fred@ecotroph.net> Randy suggests "one solution to the problem"
[14:24:54] <jishac> and pursual as a tsvwg item
[14:25:50] <jishac> Lars (co-author hat): would like to see the draft read and commented on at this point
[14:26:26] <jishac> ROOM TOPIC: Portnames Draft (Joe Touch)
[14:35:56] <jishac> Lars: [Slide 13] this brings in the DNS as a required component for communications (which is obviously not the case now)
[14:39:49] <jishac> M Mathis: How much have you thought of deployment issues
[14:40:24] <jishac> what would cause use to use this
[14:40:43] <jishac> /one to use/
[14:41:15] <jishac> Touch: If you think that this is important
[14:41:24] <jishac> Faber: That's not particularly convincing
[14:42:08] <jishac> Mathis: There are some providers that 'run out' of ports either from IANA or other use
[14:45:47] <jishac> (not sure of name): I think his concern is there is a propery of the solution with regards to specifying ports and not names? (I could be way off)
[14:46:40] <jishac> Gorry: Does this have to be extended for DCCP
[14:47:39] <faber> Actually, I heard "How is this different from DCCP serviceports?" and I didn't hear a significant difference.
[14:49:38] <jishac> faber: ah ok, thanks
[14:50:51] <jishac> I think I've my mind is completely off track on this discussion ...
[14:51:10] <faber> I keep nodding off. Need more sleep.
[14:51:42] --- fred@ecotroph.net has left: Logged out
[14:53:37] --- rono has left
[14:57:51] --- lars has left
[14:57:51] --- shikob has left
[14:57:52] <jishac> Meeting over
[14:58:01] --- faber has left: offline
[14:58:12] --- jishac has left
[14:58:28] --- mallman has left: Computer went to sleep
[14:59:28] --- sarolaht has left
[15:00:00] --- wrstuden has left: Computer went to sleep
[15:31:14] --- mallman has joined
[16:05:42] --- mallman has left: Computer went to sleep
[16:35:45] --- psavola has left
[17:02:08] --- mallman has joined
[17:09:00] --- mallman has left