[14:06:58] Simon Perreault joins the room [14:07:57] alfredh joins the room [14:08:11] hello [14:13:22] here's my server info: [14:13:32] ipv4: 130.129.29.240 [14:13:42] ipv6: 2001:df8::16:20a:95ff:fef7:a2af [14:13:58] same user as monday [14:14:22] ok [14:14:28] any changes in your server? [14:14:44] no, none [14:15:06] do you have IPv6 capability? [14:15:13] i'd really like to test that one [14:18:42] yes [14:19:06] just a second [14:20:09] looks like IPv6 is working also .. [14:21:03] are you sure? I see an ICMPv6 port unreachable... [14:22:53] Allocate Request: relay_addr=[2001:df8:0:16:20a:95ff:fef7:a2af]:49532, mapped_addr=[2001:0:53aa:64c:343e:4c4b:ad3b:29f1]:35669 [14:23:27] isn't that OK? [14:23:43] yes :) [14:23:56] when I send you the Refresh success response I receive an ICMPv6. do you see it? maybe it gets blocked along the way... [14:24:11] I close the port too early :) [14:24:15] sorry about that.. [14:24:20] uh my last statement didn't make sense [14:25:01] so anything else you want to test? [14:25:10] did you meet Marc already ? [14:25:25] yes, Marc is here trying to enable IPv6 on his laptop [14:25:38] ok, please send best regards from me :) [14:25:59] sorry I could not make it to IETF, maybe next time .. [14:26:35] how about using the turn server as an IPv4 <-> IPv6 relay [14:26:35] LAPCI0108B4863EA joins the room [14:26:45] LAPCI0108B4863EA has set the subject to: behave [14:26:56] either allocate an IPv4 address over IPv6 or vice-versa [14:27:13] LAPCI0108B4863EA leaves the room [14:27:16] TJ joins the room [14:28:00] karen.s.seo joins the room [14:33:30] Mariano O'Kon joins the room [14:35:46] RjS joins the room [14:36:49] Mariano O'Kon leaves the room [14:43:09] hi alfred [14:43:43] Philip Matthews joins the room [14:44:05] Mariano O'Kon joins the room [14:44:39] mlm.michael.miller joins the room [14:44:52] Mariano O'Kon leaves the room [14:44:58] mlm.michael.miller leaves the room [14:45:23] mlm.michael.miller joins the room [14:45:54] hey robert how are you? [14:46:04] Are there any slides posted somewhere? I can only find the agenda on the IETF web site. [14:46:43] http://tools.ietf.org/wg/behave/agenda?item=agenda73.html has more than just agenda ....PPTs / .PDFs [14:52:38] Phil Roberts joins the room [14:53:50] Meeting materials for all sessions can be found at https://datatracker.ietf.org/meeting/73/materials.html [14:54:04] dmw.winter joins the room [14:54:10] dmw.winter leaves the room [14:54:36] Dave Winter joins the room [14:54:40] Simon Perreault leaves the room [14:56:55] Simon Perreault joins the room [14:57:08] donley.chris joins the room [14:57:32] DThaler joins the room [14:57:53] Bruce joins the room [14:57:59] mhp joins the room [14:58:10] narten joins the room [15:00:39] matthijs joins the room [15:00:49] BillC joins the room [15:01:37] I assume things haven't started yet.. someone please say when things start -- in case the audio stream isn [15:01:42] isn't picking things up. [15:01:55] Correct, have not yet started ... will let you know. [15:01:57] Simon Perreault leaves the room [15:02:00] I can hear occasional coughing [15:02:12] i can hear dns talk [15:02:18] in previous sessions, some of the micrphones worked, while others did not. [15:02:28] (Starting ...) [15:02:38] thanks. I can hear... [15:03:00] hirocomb12 joins the room [15:03:10] Jean-Francois joins the room [15:03:12] ysuzuki joins the room [15:03:13] Simon Perreault joins the room [15:03:22] Agenda for session 1, slide 2 [15:03:45] ... Session2 and 3 agenda introduced [15:04:15] (slide 5) [15:04:51] Slide 6 - "Note Well" ...--> Slide 7, charter work [15:06:44] Suzanne joins the room [15:07:00] Q in room, from _____ : questions charter-relevance ... A: falls into charter text [15:07:21] Slide 8, Existing milestone review [15:07:23] arifumi joins the room [15:07:34] Slide 9, WG Doc status [15:07:53] matthijs leaves the room [15:07:56] forgot to state my name on mike. [15:08:10] arifumi asked clarification regarding nat 444 [15:08:16] (thx) [15:08:37] Chair: Call for objections WRT BEHAVE-TURN ... [15:08:50] (to adopt as WG or not) [15:09:19] ... no objections, adopted [15:09:31] Slide 10 ... [15:09:53] _____: requests and affirmitive poll on the last call for adoption .... [15:09:57] Thank you to whomever replied to my question re: slides. They weren't there 30 minutes before the session started. [15:10:18] Have not read the document [15:10:22] levigner joins the room [15:10:29] ... Room hums in favor, none opposed [15:10:41] Philip - is that a vote to delay? [15:11:06] Not really -- but I really should read it, since I am the TURN editor [15:11:14] ... back to / still on Slide 10 ... [15:12:03] Slide 11 .... "Interim" ... 2 days of BEHAVE + SOFTWIRE ... needs headcount for attendees in Malta? [15:12:56] ____: Call to prevent double-counting ... Chair: two different questions, one for room count and one for BEHAVE specifically ... [15:12:57] nm joins the room [15:14:09] Also, poll for remote attendance ... [15:14:17] +1 [15:14:53] In-room count count was "lots" ... around 30 ... [15:15:16] I counted 15 in half the room and the other room looked about the same roughly [15:15:17] On to TURN ... draft @ http://tools.ietf.org/html/draft-ietf-behave-turn ... presentation @ http://www3.ietf.org/proceedings/08nov/slides/behave-3.ppt [15:15:24] saumitra joins the room [15:16:06] Slides unnumbered ... "Changes -9 to -11" (#3) [15:16:25] Slide #4 (2/8) [15:16:29] magnus joins the room [15:17:03] Slide #5, 3/8 [15:17:20] simov joins the room [15:17:36] Cullen Jennings joins the room [15:17:42] SLide #6 (4/8) [15:17:54] maureen.stillman joins the room [15:18:17] Slide #7 (5/8) [15:18:36] Slide #8 (6/8) [15:19:05] Slide #9 (7/8) [15:19:37] DUDI joins the room [15:19:39] Phil [15:19:41] Yes [15:19:43] question from Cullen [15:19:43] ... Q from ____ : regarding "changes 7/8", bullet 1 [15:19:58] For security reasons [15:20:04] JonathanLennox joins the room [15:20:15] There was an attack where this helped [15:20:28] Can you say any more ? [15:20:30] Let's do it via e-mail [15:20:38] Slide #10 (8/8) [15:20:40] zoil joins the room [15:20:44] fair enough - that will make it easier for others to follwo too [15:21:06] Q, Adam: who plans to implement this? [15:21:31] How many people raised their hands? [15:21:31] Slide #11 "TURN Server Names" [15:21:35] 2 hands [15:21:42] Thnaks [15:21:51] I think it was about 2 people put hands up to Adams questions [15:22:02] Went back to same port after rewrite 1 year ago [15:22:24] When we introduced channels [15:22:37] ___: TS WG to define service registry [15:22:40] Thanks to Lars for the info [15:22:51] So open issue goes away [15:23:01] Adam Roach joins the room [15:23:15] We felt that having the same port would allow STUN and TURN to run on same [15:23:37] Yes -- Cullen is right [15:23:48] Cullen: questions/comments implementations about TURN vs STUN server ... [15:23:53] Philip: re the attack question earlier... if restricting is something the server could do, the draft should probably discuss the attack (if it doesn't already) to help folks know whether they want to restrict or not [15:24:10] ... why you wouldn't use the same port. [15:24:10] I think it does -- I need to look at what the draft says again [15:24:33] please use the same for port STUN and TURN :) [15:25:01] ____: FW should be smart enough. ... port-based policy not so good A: Yes, don't be broken. [15:25:11] Comment to JDR: Has been same port since fall 2007 (after we added channels). Does WG want TURN to run on different port? [15:25:52] Adam quotes Philip ... [15:25:57] Or tries [15:26:03] It's way too early in the morning [15:26:04] Thanks Adam [15:26:13] bnsmith joins the room [15:26:19] I don't care [15:26:57] ___: lots of services don't have potrts already, running registry ... send them over to me ... will be sent to IANA when serv eegistry avail. [15:27:09] that was Stuart Cheshire [15:27:15] (missed name ... thx!) [15:27:16] Got that; thanks! [15:27:33] Slide 12, 13 ... attack in progress [15:27:56] Slide 14 ... attack continues .. typo in slide (fixed in real time for those present) [15:28:07] Slide 15 ... [15:28:13] ... 16 ... still attacking ... [15:28:33] .;.. 17 ... [15:28:40] ... 18 ... [15:28:54] Slide #19, loop created ... [15:29:08] Slide 20, variant ... [15:29:33] Variant requires guessing the relayed transport address before it is allocated [15:29:37] I think [15:29:42] ____: explaining this variant [15:29:51] Adam: questions feasibility ... [15:30:11] magnus and adam discussing at mic [15:30:21] ... conversation off mic ... maybe need to reverse the arrows on the variant [15:30:53] Cullen: This is why I wanted the BW attrib in place A: Quesions feasibility of attack [15:31:05] Comment to WG: Variant requires guessing the relayed transport address before it is allocated [15:31:27] Cullen: ... referencing slide 17 ... authent. ... [15:32:07] A: Referencing slide 12 ... authneitcation happens here ... [15:32:52] ____: On path attack possible, strength of source port randomization is important to defeat off path. [15:32:57] that was Magnus [15:33:47] (I am missing lots of names, sorry!) ____: arbitrary amount of data dumped to server ... spoof ... abuse of tcp rcvrs ... [15:34:00] EKR [15:34:22] Cullen: ... that is why each TURN server has accounts and ltd BW ... maybe not ideal [15:34:30] Dave T: remind people to say names ? [15:34:30] Adam Roach leaves the room: Computer went to sleep [15:34:39] I did a minute ago, this is Remi [15:34:51] Remi: concern over use of BW as prevention [15:34:57] I'll try to call people who are up for the first time [15:35:12] Adam : Not every problem has a technical solution ... answer may not be in protocol spec ... [15:36:13] ____: Security considerations statement in protocol (Still missed the name), not technical specs? A: The infinite loop is maybe a serious enough concern [15:36:22] Slide 21 ... [15:36:28] Gregory Lebovitz [15:36:37] (thx) [15:37:11] @TJ thanks for scribing [15:37:27] On to TURN-TCP ... slide 2 now (still unnumbered) ... http://tools.ietf.org/html/draft-ietf-behave-turn-tcp ... http://www3.ietf.org/proceedings/08nov/slides/behave-2.ppt [15:37:35] BillC leaves the room [15:37:40] @Philip - no worries, sorry I don't know names/faces! [15:38:16] Slide 3 ... starvation ... [15:39:40] (EKR) [15:39:51] EKR: Buffering as the solution? [15:40:19] A: ... no infinite buffers ... [15:41:03] EKR: Seems to be saying the server should decide when to send to individual peers, not forwarding back-pressure to source... IIUC. [15:41:09] Slide 5 [15:41:51] Remi : votes in favor of this [15:42:16] Adam : May not need to reinvent the wheel; SSH windowing as an alternate solution? [15:42:46] ... conversation continues ... "this starts to look like FTP" ... [15:43:13] Remi: This proposal is easier for server [15:43:24] Slide 6 [15:44:59] Slide 7 [15:45:45] Cullen: Question on connection bind ... [15:46:33] Adam: If we do this, can we close the control while data flows. A: Good question ... [15:46:59] ... "probably not" ... future clarification [15:47:15] Slide 8, end ... call for questions ... [15:48:09] ____:Question on slide 7 ... socket call questions regarding not knowing remote side info ... [15:49:21] RjS leaves the room [15:49:39] JonathanLennox leaves the room: Replaced by new connection [15:49:39] JonathanLennox joins the room [15:49:39] Dave: votes in favor of this approach; other use cases follow similar model ... works well ... optional negotiation over control to remote side? [15:50:24] That was me with the question about socket calls [15:51:06] Greg: Why can't the TURN server just acknowledge congestion on specific peer connections ... [15:51:37] A: Client only has one window in this case, a "lowest common denominator" type of thing ... [15:52:43] ... continues ... why need a separate control-data model, vs a "clean" per-peer-TURN ...(Adam) because the client doesn't alway know how many peers are coming back ... [15:53:31] Dan York joins the room [15:55:04] ... continues ... does the control-data model mean that the middle boxes (think FW, NAT) need to understand this? ... A: all accounted for, regular sessions flowing ... taking it offline [15:55:23] ... rough consensus for this draft? Any objections? [15:55:28] Show of hands ... ? [15:55:43] Vote yes [15:56:00] That is, vote in favor of JDR's proposal [15:56:19] roughly 13 yes - 1 no - 6 don't cares [15:56:31] John: who plans on implementing this? [15:57:11] Comment to WG: We need to progress ICE-TCP at the same time [15:57:15] ___: Yes we should solve this, but not familiar enough with this and alternatives to vote ... [15:57:19] i think that was EKR who asked who planned to implement? [15:57:19] Otherwise no point [15:57:47] Remi: this also takes advantage of all the other transport stuff ... [15:58:19] On to SCTP ... http://tools.ietf.org/html/draft-ietf-behave-sctpnat ... http://www3.ietf.org/proceedings/08nov/slides/behave-1.pdf [15:58:37] ... Slide #2 ... [15:58:51] Slide #3 [15:59:23] Sorry, who's the speaker? [15:59:33] Michael Tuxen [15:59:39] Thank you. [16:00:12] Misspelling his last name, it is Tuexen [16:00:37] Or actualy Tüxen [16:01:28] Slide 5 [16:02:43] Slide #6 [16:03:38] Adam Roach joins the room [16:04:04] Magnus: Terminology is not consistent with existing work ... [16:04:35] Simon Perreault leaves the room [16:04:37] Jean-Francois leaves the room: Computer went to sleep [16:04:38] A: We can call them whatever works best, but remember that we do not modify port # [16:04:55] Remi: Q on Slide 4 ... [16:05:39] ... existing NATs do ____? Translate address only, limiting to one internal user under best case ... ? [16:06:21] A: we are talking baout mod to existing NAT functionality ... [16:07:12] ___: Answers questions .. vtag to peer mismatch, connection discarded ... would fail - like it odes now anyway [16:07:15] wolfgang.beck01 joins the room [16:07:42] Remi: terminology suggestion - "internal-external-remote" [16:07:50] Simon Perreault joins the room [16:07:52] joins the room [16:07:59] ... send text to author [16:08:20] Jean-Francois joins the room [16:08:49] ____: Good randomization required ... A: NAT box enforces this (per this doc) [16:09:06] that was Jonathan Lennox [16:09:19] Stuart: Proposal of "future NATs" ... solicits NAT vendors input ... any in room? [16:09:41] Cullen: Knowledge of Linksys efforts ... [16:10:55] Brian: vtag is clever hack, part good ... but also concerned about pushing transport layer awareness (port #s) down to layer 3 and up to layer 7 ... SCTP transport ID here becomes IP addr, port #, vtag [16:11:35] ...raises problems where this gets pushed into other areas ... NAT, TURN, etc. [16:12:44] James: (Apple NAT aware person) ... NATs already need special handling ... ESP disabmiguation, ICMP, etc. ... this is not terribly scary/crazy [16:12:57] magnus leaves the room [16:13:01] (James Woodyatt) [16:13:56] John (I think): endpoint independent mapping concern ... [16:14:05] Simon Perreault leaves the room [16:14:16] Jonathan Lennox [16:14:40] A: global IPs, ports ... session works just fine, SCTP accomodates this ... explained in draft, tested [16:15:21] Lars: in BEHAVE specifically to "encourage" NAT vendors to follow this approach (and similar for DCCP) [16:15:59] ____: low margin NAT industry .. are they listening to us? [16:16:41] Lars: lots of features available now, some SPs making prereqs on vendors [16:17:19] ... w/o a doc we know it won't happen ... so we should make a doc ... [16:17:32] Dave : Concern over hairpinning, should be added to draft [16:17:41] Slide 7 [16:17:48] donley.chris leaves the room [16:18:10] leaves the room [16:18:15] I was unclear on the response about endpoint independent mapping. Anyone know where in the draft inbound connections are addressed? [16:18:44] Slide 8 ... and a call for comments ... [16:19:08] wolfgang.beck01 leaves the room [16:19:15] arifumi leaves the room [16:19:22] Thank you to whomever is scribing! [16:19:28] zoil leaves the room [16:19:30] saumitra leaves the room [16:19:41] @Karen: My pleasure! ... [16:19:41] nm leaves the room: Replaced by new connection [16:19:41] thanks TJ [16:19:43] nm joins the room [16:19:59] Adam Roach leaves the room: Computer went to sleep [16:20:09] @Bruce: maybe around 12.5. Peer-to-Peer Communication ? [16:20:14] hirocomb12 leaves the room [16:20:20] mhp leaves the room [16:20:21] Suzanne leaves the room [16:20:51] karen.s.seo leaves the room [16:21:49] --fin [16:21:56] TJ leaves the room [16:22:59] DThaler leaves the room: Replaced by new connection [16:23:05] DThaler joins the room [16:23:12] DThaler leaves the room [16:24:28] DUDI leaves the room [16:24:47] Philip Matthews leaves the room [16:25:50] narten leaves the room [16:26:02] Bruce leaves the room [16:26:41] stpeter joins the room [16:27:13] stpeter leaves the room [16:28:23] Dan York leaves the room [16:29:22] maureen.stillman leaves the room [16:29:29] JonathanLennox leaves the room [16:30:24] ysuzuki leaves the room [16:30:38] arifumi joins the room [16:30:50] arifumi leaves the room [16:32:56] Jean-Francois leaves the room: Replaced by new connection [16:32:56] Jean-Francois joins the room [16:33:20] levigner leaves the room [16:33:43] Cullen Jennings leaves the room [16:35:29] Phil Roberts leaves the room [16:44:54] simov leaves the room [16:57:15] alfredh leaves the room [16:58:31] Mariano O'Kon joins the room [16:59:03] Mariano O'Kon leaves the room [16:59:28] Dave Winter leaves the room [17:01:33] Jean-Francois leaves the room [18:31:40] mlm.michael.miller leaves the room [19:43:46] donley.chris joins the room [19:49:13] donley.chris leaves the room [20:01:29] nm leaves the room [21:32:09] danwing joins the room [21:32:14] danwing leaves the room [22:37:41] nm joins the room [22:39:50] nm leaves the room