[10:59:48] --- leslie-ietf has joined
[11:51:28] --- dthaler has joined
[11:52:13] * dthaler has changed the subject to: SAFE - Self-Address Fixing Evolution BoF
[11:57:17] --- alfredh has joined
[11:59:10] --- leslie-ietf has left
[11:59:32] --- richard.barnes has joined
[12:00:15] --- lars.eggert@googlemail.com has joined
[12:02:36] --- TJ has joined
[12:05:38] --- magnus has joined
[12:05:41] <dthaler> Problem statement and scope ......................... (Wing, 15)
[12:07:43] --- presnick has joined
[12:08:16] --- dcrocker has joined
[12:09:10] --- leslie-ietf has joined
[12:12:16] --- presnick has left
[12:12:59] --- TJ has left
[12:13:32] --- jiang_xing_feng has joined
[12:14:07] --- resnick has joined
[12:16:57] --- jiang_xing_feng has left
[12:17:28] <dcrocker> content on this session seems a bit thin, so far.
[12:19:04] --- nm has joined
[12:20:40] <dthaler> discussion of whether scope should be limited to UDP, since problems happen with TCP too
[12:20:49] <dthaler> (scope of the BOF)
[12:22:24] <dthaler> Survey of existing work ........................... (Barnes, 30)
[12:22:29] <leslie-ietf> (thanks dave!)
[12:22:30] <dthaler> draft-eggert-middlebox-control-survey-01.txt
[12:22:57] <dthaler> surveyed only 12 of the protocols out there
[12:25:47] <dcrocker> (anytime, leslie...)
[12:26:40] <dthaler> going through the key features of each protocol surveyed
[12:30:52] <dthaler> someone at mike mentioned H.248.37 is another
[12:31:16] <dthaler> lars: yeah there's other protocols not surveyed because we couldn't find someone to write a paragraph on it
[12:32:17] <dthaler> comparison slide showing protocol, Implemented (Y/N), Widely Deployed (Y/N), Supports Incremental Deployment (Y/N)
[12:35:23] <dthaler> definition of last column is unclear and debatable
[12:36:17] --- badra has joined
[12:36:52] <dthaler> next comparison slide has columns: Keepalive reqd?, Interacts directly with middlebox?, Security between middlebox and endpoint?
[12:37:02] <dthaler> (last column is authentication & authorization)
[12:37:47] <dthaler> next comparison slide has questions: Topology Aware?, Supports nested NATs?, Supports diverse environments/endpoints?
[12:38:32] <dthaler> unclear what definition of topology aware is
[12:39:01] <dthaler> (presenter is not an author of the draft, but rather a neutral party...)
[12:41:52] --- jiang_xing_feng has joined
[12:43:03] <dthaler> interrupting regular discussion, current discussion/clarification about purpose of bof (non-wg forming)
[12:43:49] <dthaler> ok back to the slide...
[12:45:15] --- nm has left: Replaced by new connection
[12:46:13] --- nm has joined
[12:47:17] <dthaler> third column is fairly fuzzy
[12:47:33] <dthaler> summary: only widely deployed ones are SOCKS, UPnP, STUN
[12:47:36] --- jiang_xing_feng has left: Replaced by new connection
[12:48:47] <dcrocker> (stun is widely deployed??)
[12:49:10] <dthaler> apparently (I suspect that's correct)
[12:51:01] --- jiang_xing_feng has joined
[12:51:32] <dthaler> Henning: any solution requires NAT vendors to play along, anything else we would want NAT vendors to do if they play along?
[12:53:26] <dthaler> slides for the BOF are combined at http://www3.ietf.org/proceedings/07dec/slides/safe-0.pdf
[12:54:13] <dthaler> ?: most solutions never got deployed, so need something NAT vendors actually want and will do
[12:54:55] <dthaler> summary slide also said: only a few of the solutions (surveyed) effectively support incremental deployment: STUN, SOCKS, AFWC
[12:55:17] <dthaler> (but inc deployment was a fuzzy definition, per earlier discussion..)
[12:55:55] <dthaler> NAT/Firewall control with STUN ...................... (Wing, 15)
[12:56:01] <dthaler> draft-wing-behave-nat-control-stun-usage-05.txt
[12:56:08] <dthaler> Cisco has an IPR statement about this draft
[12:57:20] <dthaler> currently on slide 23 of the master deck
[12:58:03] <dthaler> goals are reduce keepalives when can, but still work on any network
[12:58:32] <dthaler> current UDP-only (could be extended to TCP but UDP is the current pain point)
[12:58:34] --- nm has left
[12:59:24] <dthaler> slide 26: Procedure with Firewall
[13:01:01] <dthaler> initial exchange with external server asks middlebox to identify itself
[13:02:28] <dthaler> procedure with 1 nat is similar... stun already gets ip address of nat
[13:02:39] --- hta has joined
[13:05:31] <dthaler> then send control to that address to ask it to extend/learn the lifetime for the 3 tuple (independent of destination)
[13:05:53] <dthaler> this may result in the lifetime for many mappings (for different dest addrs/ports) being updated
[13:06:45] <dthaler> to work with multiple layers of NAT, use outermost middlebox as if it were the server to learn the next outermost NAT's address, and repeat
[13:07:05] --- jiang_xing_feng has left
[13:08:40] <dthaler> this procedure happens in parallel with actual media flow since this is just an optimization
[13:09:22] <dthaler> if any NAT can't extend then fall back to regular keepalives but may not need to go out all the way to the internet
[13:10:34] <dthaler> remi demis-...: sending keepalives to a farther NAT (not final destination) doesn't work if the inner nat that doesn't support it uses different timers per destination address
[13:14:15] <dthaler> discussion of case of nested nats where two nats in the chain have the same ip address
[13:17:21] --- badra has left
[13:20:10] <dthaler> (a bunch of discussions about solutions, whether this case is important, more discussion about possible solutions...)
[13:20:12] --- nm has joined
[13:20:31] --- nm has left
[13:21:39] <dthaler> back to the presentation (slide 43 now)
[13:22:36] <dthaler> summary: works with nested NATs, incrementally deployable since used as an optimization and falls back to normal, no additional security policy/config in NAT
[13:23:35] <dthaler> Discussion ................................................ (20)
[13:31:20] <dthaler> two roughly orthogonal pieces: learning addresses of middleboxes, and then talking to them
[13:31:53] <dthaler> the linkage just seems to be that the source address/port used for data, learning middleboxes, and talking to mdidleboxes all need to be the same. but otherwise could be different protocols.
[13:32:12] <dthaler> (my comment above and continued...)
[13:32:58] <dthaler> multiple use domains exist: STUN, IPsec NAT-T, Teredo, native IPv4 or IPv6 with firewalls, etc
[13:33:17] <dthaler> so questions are: do we want each use domain to do it separately, or have a common mechanism
[13:33:28] <dthaler> and should learning & control be same protocol or different
[13:33:36] <dthaler> and should they be a protocol in the surveyed list, or something new
[13:33:43] <dthaler> that's what we need discussion about
[13:34:06] <dthaler> (end of my own comments)
[13:35:57] <dthaler> cullen: while NATs only do TCP and UDP, if you want a solution for firewalls then other protocols matter too
[13:37:47] --- hta has left
[13:41:06] <dthaler> lars: nat vendor has no incentive to put this on the box (no benefit), how do you convince the nat vendor to do something?
[13:41:14] --- nm has joined
[13:42:49] --- ldondeti has joined
[13:44:05] <dthaler> discussion (Keith Moore, Jonathan Rosenberg) about whether solution should be broad or narrow, to increase liklihood of market adoption
[13:46:40] <dthaler> rosenberg: one business case is where the server and the middleboxes are owned by the same entity (e.g. cable operator), since the server benefits from decrease in load
[13:51:40] --- nm has left
[13:52:46] <dthaler> Aki Nemi: SIP-Outbound was on the list of uses, but that should move to TCP not UDP
[13:54:03] --- nm has joined
[13:55:01] <dthaler> Keith Moore: seems to be adding more complexity into the network for a small incremental gain
[13:55:29] --- hta has joined
[13:55:36] --- ilya has joined
[13:59:30] <dthaler> Hannes: also a benefit to the hosts who can conserve battery more
[13:59:56] <dthaler> Future directions ................................. (Chairs, 30)
[14:00:35] <dthaler> chais will ask 3 questions
[14:00:52] <dthaler> 1) Are some functional requirements or deployment considerations left unsatisfied by existing protocols?
[14:01:10] <dthaler> 2) Is there agreement that the IETF should consider developing a new NAT control mechanism to address these requirements?
[14:01:29] <dthaler> 4) Is the NAT Conrtol STUN Usage a reasonable approach to NAT control, addressing the requirements?
[14:03:01] <dthaler> (4 shoudl be 3 above)
[14:03:18] <dthaler> also 2 & 3 could be separated into discovery vs control, but combined for the moment
[14:03:24] <dthaler> now asking question #1
[14:04:37] <dthaler> some studies claim keepalives can consume up to 50% of battery in some cases
[14:05:37] <dthaler> really discussing "is there a problem" first
[14:06:06] --- nm has left: Replaced by new connection
[14:06:07] --- nm has joined
[14:06:23] --- nm has left
[14:09:05] <dthaler> Rosenberg: three categories... P2P is arguable as to mostly solved with ICE, Client-Server has no real problem here, but Push (i.e. subscribe to notifications) is the category that has unsolved requirements
[14:10:05] <dthaler> Moore: disagree completely, harder and harder to put up rendezvous servers (addr scarcity), and harder to develop new applications
[14:10:50] <dthaler> (so far people are generally arguing that the answer to #1 is Yes)
[14:13:14] <dthaler> ?: Power-save modes typically kick in after 2 minutes, so sending keepalives every 30 seconds prevents any power saving. Using TCP instead, for example, is a whole lot better.
[14:13:59] <dthaler> Aboba: suggests maybe a Study Group (or whatever the experiment is called) to explore
[14:14:22] <dthaler> taking a hum...
[14:14:34] <dthaler> ok Yes wins
[14:14:47] <dthaler> (of those in the room anyway, very few nos...)
[14:15:45] <dthaler> Re-asking...
[14:16:38] <dthaler> Q1.5: Is frequent keepalives, such a requirement that is left unsolved by existing protocols?
[14:16:53] <dthaler> er "avoiding" frequent keepalives
[14:17:07] <dthaler> ok hums say Yes (not unanimous, but overwhelming majority)
[14:17:17] <dthaler> now asking #2
[14:20:11] --- dcrocker has left
[14:23:02] <dthaler> changed question to "Should the IETF try to solve the above problem?"
[14:23:12] <dthaler> ok hums said Yes
[14:26:22] <dthaler> now discussion question #3
[14:26:32] --- resnick has left: Lost connection
[14:26:59] <dthaler> some feedback that TCP is important to address to, and other protocols (Teredo, etc) that have the same problem... is the solution applicable to them or not... as phrased the question is unclear
[14:27:58] <dthaler> stun control today is IPv4 UDP only
[14:29:57] --- hta has left
[14:33:18] --- nm has joined
[14:33:37] --- nm has left
[14:33:39] <dthaler> asked question 3 with ansewrs: yes, no, maybe unclear so far
[14:33:51] <dthaler> yes and unclear about equal, no's were quieter
[14:34:16] <dthaler> lars asking whether we can do something that vendors will want to put on their box...
[14:34:37] <dthaler> about 1/3 yes, about 2/3 no
[14:34:52] --- richard.barnes has left
[14:37:19] <dthaler> <end of meeting>
[14:41:44] --- lars.eggert@googlemail.com has left
[14:46:00] --- leslie-ietf has left
[14:49:43] --- ldondeti has left
[14:50:06] --- ilya has left: Disconnected
[14:58:48] --- hta has joined
[15:02:38] --- magnus has left
[15:11:39] --- dthaler has left
[15:19:18] --- hta has left
[20:21:18] --- alfredh has left
[22:04:01] --- apn has joined
[22:04:10] --- rdenisc has joined
[22:05:14] --- rdenisc has left
[22:05:17] --- apn has left