[11:39:28] jpdionne joins the room [11:54:06] jpdionne leaves the room [12:59:07] SwedeMike joins the room [12:59:20] Tony joins the room [13:05:11] Hugh_Daniel joins the room [13:05:45] danwing, this is ietf-80... [13:07:40] tomkrist joins the room [13:08:10] leo joins the room [13:10:00] danwing joins the room [13:10:29] danwing has set the subject to: BEHAVE, IETF80 [13:13:44] shinmiyakawa joins the room [13:17:04] shinmiyakawa leaves the room [13:19:33] iljitsch joins the room [13:19:52] someone is fighting with the microphone [13:20:09] Ole Troan joins the room [13:20:21] do we need a jabber scribe? we have audio [13:20:40] iljitsch pokes back [13:20:41] jpdionne joins the room [13:20:44] Chris Griffiths joins the room [13:20:45] becarpenter joins the room [13:20:47] Now 9. [13:20:53] t.k joins the room [13:21:02] fdupont joins the room [13:21:45] cheshire joins the room [13:22:15] cheshire leaves the room [13:22:18] cheshire joins the room [13:22:23] cheshire leaves the room [13:22:31] cheshire joins the room [13:22:35] stuart has trouble making up his mind. :-) [13:22:58] The agenda Jabber URL didn't have the "?join" at the end [13:23:04] Was experimenting [13:23:23] I don't know what the "?join" does, but without it, it doesn't work right [13:23:31] will fix for ietf81 [13:23:55] I'll update the draft this week [13:24:17] tx! [13:24:20] Trond joins the room [13:25:20] John Dong joins the room [13:25:44] Ole Troan leaves the room: Disconnected. [13:26:31] ywang830 joins the room [13:27:14] Ole Troan joins the room [13:27:39] Dave Thaler asks: anyone interested in SCTP NAT? [13:28:02] jpc joins the room [13:28:31] stuart: try this: http://www.bgpexpert.com/ietfxmpp.php [13:29:19] John Dong leaves the room [13:29:30] (oh wait, you were experimenting, I thought you simply had trouble typing the right URL) [13:30:23] ayourtch joins the room [13:31:02] gigix73 joins the room [13:32:40] shengjiang joins the room [13:33:07] Atarashi Yoshifumi joins the room [13:35:54] shinmiyakawa joins the room [13:38:07] Without the "?join", it appears to try to do a chat to a "person" called "behave@jabber.ietf.org " rather than joining a group with that name. [13:38:16] ah [13:38:31] I think in the US working groups are legally persons [13:40:40] Suz joins the room [13:41:00] Moving to: Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen) draft-korhonen-edns0-synthesis-flag draft-savolainen-heuristic-nat64-discovery draft-korhonen-behave-nat64-learn-analysis [13:41:23] swb joins the room [13:42:04] geir joins the room [13:44:20] dougm.home joins the room [13:51:32] narten joins the room [13:51:56] could people please stop manhandling the microphones? [13:53:24] the thing is that putting stuff in the DNS is easy for operators [13:58:21] arifumi joins the room [14:01:21] magnus joins the room [14:01:41] Audo is lost [14:02:09] Jabber was slow to respond. Link problem at IETF? [14:02:41] I'm not having any trouble on my end [14:02:46] Audio flows towards me [14:02:58] andrew's frustration is coming through loud and clear [14:03:15] I restarted my end. [14:03:38] which presentation are we at? [14:03:43] avoid NAT64? [14:03:56] still Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen) draft-korhonen-edns0-synthesis-flag draft-savolainen-heuristic-nat64-discovery draft-korhonen-behave-nat64-learn-analysis [14:03:59] I think [14:04:03] thanks [14:04:08] the edns0 one [14:04:17] or discovery? not sure [14:06:46] Mohamed Boucadair presenting the NAT64 Analysis document [14:06:57] PLEASE MIND THE MIKE! [14:07:23] it's like you guys are having the session in a thunderstorm, not good when listening with headphones [14:08:57] Shin presenting CGN Requirements document. [14:09:15] maybe mic is too close [14:09:41] yeah, it's clipping badly [14:10:26] so badly the speaker cannot be understood? [14:10:31] no [14:10:34] sounds perfect in the room, for whatever that's worth [14:11:00] no=cannot be understood, or no=can be understood [14:11:04] the volume is also very high, so it might be amplification before it goes out to the stream [14:11:05] but it seems like people are really abusing the microphone [14:11:09] I can understand him [14:11:12] danwing: I can understand him. [14:11:13] ok [14:14:34] chairs: I updated the FTP64 draft [14:15:55] Thanks, Iljitsch. [14:18:15] do we really want to go into congestion stuff in CGN discussion? [14:19:08] Gregory Lebovitz joins the room [14:20:48] It would be good if we get to see the port limits as they're imposed rather than hitting a brick wall when 10% of the users upgrade an application so it starts using way more ports or some such. [14:21:06] i'm joining remotely from santa cruz [14:21:29] anyone care to jabber scribe for things like slide number, who is at mic, etc? [14:21:36] no [14:21:38] :-) [14:21:45] OUCH!!! [14:21:48] 16:40 NAT64 Load Balancing (Dacheng Zhang, 10) draft-zhang-behave-nat64-load-balancing milestone date: April 2011 [14:21:51] MIND THE MIKE!!! [14:22:00] thx dw [14:22:03] this is better [14:22:08] yes, much better [14:22:11] no clipping [14:22:31] but it's so annoying that people are pawing at the microphone all the time [14:25:05] NON-CHARTERED ITEMS: 16:50 RADIUS Extensions for NAT Forwarding Port (Dean Cheng, 10) draft-cheng-behave-nat-fwd-port-radius-ext-00 [14:25:25] bcheck joins the room [14:25:27] AAAAAHHHHHH!!!!! [14:25:33] The issue is when people clip the mic to the neckband for the badge, rather than the cloths. Then it dings around and creates sounds. [14:25:46] sdstrowes joins the room [14:25:47] And of course when they try to attach it. [14:25:48] no the problem is when switching speakers [14:25:52] Atarashi Yoshifumi leaves the room [14:26:10] these lapel things don't work for this kind of stuff [14:26:21] IETFers don't have lapels [14:26:31] Well, you would need to mute the mic before actually handling it. It can't be handeled without creating sournds. [14:27:00] or use one on a stand or a handheld one [14:27:03] takes time. we are pressed for time more than we are pressed for noise on the audio. [14:27:16] no handheld mic here, except the audience mics [14:27:22] Iljitch: a locally-controlled workaround is to take off the headphones when the speakers switch. [14:27:31] how is the service request done in the scenario done on slide 3? [14:27:33] ok warn us then [14:27:53] is it uPNP? [14:28:46] on slide 3. [14:28:53] slide 3 doesn't look at all like UPnP IGD. [14:29:07] could you please ask the speaker? [14:29:23] @Dan: What was the specific question you asked about draft-zhang-behave-nat64-load-balancing? I saw no one in the room spoke up, but I missed the exact question. [14:30:59] right, whatever provisioning is being used is on the front end. This is going to solve how to return provisioning info. [14:31:23] AND the client would need to support the type [14:31:35] Stuart: the question I asked was to the effect of "who has read the draft", we got 8 hands. I remarked that we have a WG milestone for NAT64 load balancing, and asked if anyone had interest in NAT64 load balancing. Nobody came to the mic. [14:31:37] yeah, I don't understand how the user will know the outside port. [14:31:40] and the stack needs to be able to accept and use the port mappings too [14:32:26] @ SwedeMike: I think the idea is that he won't. The AAA server is going to tell him what to use. Once told, he has to be able to know how to USE it, I.E. changes in his stack [14:32:45] oki, thanks. [14:32:52] i'm guessing it's provisioned, like the IP is, at the SPs desire [14:33:04] am I guessing this correctly? [14:33:16] lebobits: from what I hear, I interpret it the same way. [14:34:12] note to self: multiple ports NOT SUPPORTED [14:34:22] yeah that's useful [14:34:36] I only run apps on port 80 anyway [14:34:39] [14:35:18] yeah, I don't get it. [14:35:34] I could understand a range of ports, like a block of 100. [14:35:39] @ mic: in order to do this we would also need corresponding attributes standardized in both DHCP and PPP, right? [14:36:03] lebobits: non-starters [14:36:06] especially PPP [14:36:23] we really need more tools than the DHCP hammer [14:37:06] … and user stacks need to support on ea OS, right? [14:37:23] lebobits: couldn't parse that [14:37:24] I don't really understand the use-case for a single port. [14:37:29] not poking holes, just trying to understand the set of changes needed completely [14:37:57] Gregory, I don't see any DHCP or PPP changes needed for draft-cheng-behave-nat-fwd-port-radius-ext [14:38:09] the IETF has been spectacularly unsuccessful in making provisioning from service providers to customers happen in a sane way [14:38:44] 17:00 NAT64-CPE Mode Operation for Opening (Gang Chen, 10) Residential Service draft-chen-v6ops-nat64-cpe [14:38:47] @ dw: once that info gets passed from AAA to BNG, doesn't it need to then be communicated to the end-user client? [14:38:49] PPP was ok, but the rest is ugly hack after ugly hack [14:39:13] Gregory: no. The port forwarded was configured earlier, out of band, using HTTP or by calling an 800 number, or whatever. [14:39:24] Please stop attacking the mic... [14:39:56] oh. We remotely all thought it was then passed in dhcp or ppp or whatever the service request was initially [14:40:05] thx for clarifying [14:40:20] Just like today, you make NAT mapping on your Linksys's web page [14:40:27] Nothing tells your PC you did that [14:40:32] Gregory, your question came up in the room, too; but part of the answer was probably communicated without using a mic. [14:40:42] It just starts getting inbound connections [14:41:00] slide title "CPE Mode Scenarios" [14:41:05] stuart: you must be a big fan of that approach where the user copies and pastes port numbers [14:41:07] thx for clarification, gents [14:42:29] tomkrist leaves the room: Replaced by new connection. [14:42:40] @iljitsch You need to explain the sarcasm for the benefit of others [14:42:54] tomkrist joins the room [14:43:35] it's phenomenal to what lengths we will go in order to avoid dual-stack. [14:44:08] ok guys, please read this wikipedia article to fully understand my previous comment: http://en.wikipedia.org/wiki/Wikipedia:Sarcasm_is_really_helpful [14:48:55] next up: [14:48:56] 17:10 Analysis of Solution Candidates to Reveal (Mohamed Boucadair, 15) the Origin IP Address in Shared Address Deployments draft-boucadair-intarea-nat-reveal-analysis [14:50:31] gigix73 leaves the room [14:51:43] we on slide 3 now? [14:52:51] can someone call out what slide we are on? [14:53:04] Slide 7 [14:53:13] thx magnus [14:53:21] 8 [14:58:22] this has existed since NAT was invented, on IRC it's very common. Have had problem with it for 15 years. [14:58:49] and spam, and as a response to attacks observed in IDS/IPS [14:58:55] people keep saying "this" but what are they getting at? [14:58:56] Ole Troan leaves the room: Disconnected. [14:59:16] I had an idea of using ident back then, so that the NAT would give a consistent ident response on who was behind the connection, but I don't think that would work today :P [14:59:34] iljitsch: the problem of wanting to block one person behind the NAT, but having to block them all. [14:59:58] move to IPv6 and don't tell people about RFC 3041. [15:00:59] 3G providers already add an HTTP header that identifies the user in some cases [15:01:05] iljitsch: well, for IPv6 I would like to use the allocation policy of the site for blocking, so usually either /128, /64 or /56 or whatever is "one administrative domain" [15:01:09] although they've reduced this recently, I think [15:01:15] probably for privacy reasons [15:01:49] why don't these sites just require people to sign up? [15:02:02] this address based filtering has never worked and never will [15:06:44] sandoche joins the room [15:06:46] they shouldn't TRUST it, they should use it for tracking. It's additional information, like source port. [15:06:47] where would the host id go, btw? [15:07:15] so it's one more thing to add to a abuse report. But I guess the author wants to block on it, and that's not going to happen. [15:07:35] why are we wasting time and energy on trying to keep IPv4 running??? [15:07:50] seems to me to solve this right would require a good deal of work and would need to be broader than NAT [15:08:02] for instance, we really need this (and have failed to get traction) for email [15:08:52] I think we should bring back IDENT. [15:09:03] tony: isn't that in the IETF's mission statement by now? :-) :-( [15:09:10] 113/tcp isn't used enough today. [15:09:58] also, the CGN would work really nicely with 100k ident requests per second (because it's doing 100k tcp sessions per second) :P [15:10:27] maybe the CGN shouldn't forward 100 kpps synfloods [15:10:30] just saying [15:11:16] swb leaves the room: Disconnected. [15:13:12] swb joins the room [15:13:17] @SwedeMike, I have an I-D on doing this with IDENT. It can't work, because an attacker will overwhelm the IDENT server. @iljitsch, the CGN operator cannot identify an attack versus legitimate traffic; the SYN attack is but one example of an attack that a person can reasonably visualize in their head [15:14:27] danwing: you need a pretty big number of SYNs per second to do a synflood these days. The CGN could certainly dectect that, and really should to protect its own resources [15:14:36] danwing: wow, I thought everybody had forgotten about ident, have never heard about it outside IRC as of 10 years ago. [15:15:13] @iljitsch: s/syn flood/GET flood, sent over TLS/ [15:15:30] I don't think these mechanisms are useful in DoS mitigation, leave that up to the CGN operators or block the whole address [15:16:01] you may need it for other bad behavior, which should happen at relatively low rates so ident type solutions could work [15:16:50] +1 — what lorenzo said [15:16:52] +1 to Lorenzo's comment. Lets spend the energy getting v6 to work [15:17:18] "This is too complicated to be robust" is a brilliant statement of a basic principle. [15:17:43] that goes along w/ my earlier comment: it's phenomenal to what lengths we will go in order to avoid moving to ipv6. [15:17:51] I worry that if this takes off for v4 people will want it for v6, too, chipping away even more at e2e because the ISP would have to sit in the middle for this funciton [15:19:52] iljitsch: I would like the ISP to publish the allocation policy, so I know what a single user is. [15:20:02] and it needs to be available on the fly. [15:20:16] next up: [15:20:17] 17:25 NAT64 Management Information Base (MIB) (Jean-Philippe Dionne, 10) draft-jpdionne-behave-nat64-mib [15:20:39] slide 2 [15:21:05] mikaabra: I would rather move away from attaching unnatural meanings to the IP address a user happens to have at a particular moment in time [15:21:15] slide 4 [15:21:25] such as all the sites that talk to me in Spanish because I'm in Spain. I hate that. [15:21:30] iljitsch: do you have a better solution for doing blocking? [15:21:40] Yes: use a login [15:21:48] doesn't have to be one for the site in question [15:21:53] could be from an identity provider [15:21:58] Iljitch: login does not help with synfloods [15:22:32] I'm not sure what you have in mind for blocking syn floods [15:23:23] CGNs shouldn't let them through in the first place and the only way to do stuff at this level is add an identifier to each SYN, which would be bad [15:23:33] slide 7 [15:23:33] TCP option space is at a premium as it is [15:25:00] iljitsch: what about services that have free logins, is the solution for that to use captchas? seems like a lot of extra work for the customer [15:25:25] gl joins the room [15:25:35] becarpenter leaves the room [15:25:59] I guess for people like Rapidshare what they want is to rate limit access to a particular user [15:26:09] same for forum flame wars [15:26:27] you could tell people to use an openid login [15:26:31] but they could have many of those [15:26:44] so it doesn't solve THAT problem [15:27:05] btw, we already do the ident to every syn packet in order to stop syn floods, it's called syn cookie [15:27:21] for me it's more a blocking thing, I want to block a certain administrative entitity which could be a home, a DC customer, or something. [15:27:30] lebobits: I think we have different definitions of "ident" [15:27:50] lebobits: syn cookies only says that the other end can see our return packet, not any unique identifier. [15:28:03] yes, but my point is that we have a way to block syn floods based on validation of appropriate user and i'm not sure we need to solve it again [15:28:34] that solves the "you stole my addr and put it on pkts u sent" problem [15:29:29] yes, but that's not what I'm talking about. [15:29:58] I'm talking about "there is this jerk logging into my linux channel saying "linux sucks" and I never want to see him again" [15:30:44] people who are that invested into being jerks can find proxies [15:31:12] yes, but it makes it harder. [15:31:30] I'm not against that [15:31:47] as long as it doesn't mean rewriting all SYNs and using up valuable option space [15:31:58] I never thought that was a good idea. [15:35:46] Gregory Lebovitz leaves the room [15:37:32] now up: 17:35 Report on Monday's Multicast Bar BoF (Stig Venaas, 20) [15:38:43] Slide 6 [15:42:57] Chris Griffiths leaves the room [15:44:15] sandoche leaves the room [15:45:44] Ole Troan joins the room [15:45:46] Just say NO !!!! [15:46:07] This is not a new topic, it was discussed for too long 10 years ago [15:46:31] There are no good solutions... Just stop wasting energy on the IPv4 side [15:46:55] Trond leaves the room [15:48:28] The problem is that from now on, IPv4 will only get worse [15:48:36] Ole Troan leaves the room: Disconnected. [15:48:43] we can make it less worse, but is it worth the trouble? [15:52:50] unintelligible [15:53:09] this is just noise on the mic [15:53:28] arifumi leaves the room [15:53:55] fdupont leaves the room: Computer went to sleep [15:56:56] dougm.home leaves the room [15:58:59] jpc leaves the room [15:59:02] magnus leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [15:59:12] danwing leaves the room [15:59:26] jpdionne leaves the room [15:59:30] t.k leaves the room [15:59:37] geir leaves the room [16:00:25] ywang830 leaves the room [16:00:40] shinmiyakawa leaves the room [16:00:46] bcheck leaves the room [16:00:55] sdstrowes leaves the room [16:01:15] leo leaves the room [16:01:16] Tony leaves the room [16:01:40] shengjiang leaves the room [16:01:42] ayourtch leaves the room: Disconnected. [16:01:48] iljitsch leaves the room [16:03:45] swb leaves the room: Disconnected. [16:09:44] tomkrist leaves the room [16:13:03] shengjiang joins the room [16:13:31] Ole Troan joins the room [16:13:49] shengjiang leaves the room [16:16:59] cheshire leaves the room [16:20:31] gl leaves the room [16:35:09] Suz leaves the room [16:38:28] Ole Troan leaves the room: Disconnected. [16:39:07] narten leaves the room [17:20:44] Hugh_Daniel leaves the room [20:18:33] leo joins the room [20:57:53] leo leaves the room [21:26:06] jpdionne joins the room [21:37:20] jpdionne leaves the room [21:37:23] jpdionne joins the room [22:21:51] jpdionne leaves the room [22:49:08] SwedeMike leaves the room