behave - Tuesday, March 12, 2013

behave

behave@jabber.ietf.org

Tuesday, March 12, 2013< ^ >

Dave Thaler has set the subject to: BEHAVE WG meeting

Room Configuration

Room Occupants

GMT+0
[19:12:41] jochen.koegel joins the room
[19:12:49] jochen.koegel leaves the room
[19:15:31] SwedeMike joins the room
[19:20:50] <SwedeMike> url to presentations?
[19:21:12] jochen.koegel joins the room
[19:22:43] Wes George joins the room
[19:22:50] <Wes George> any remote participants?
[19:23:04] <jochen.koegel> yes
[19:23:09] <Wes George> audio ok?
[19:23:13] <jochen.koegel> allright
[19:23:14] <Wes George> I'll jabber proxy
[19:23:19] <jochen.koegel> thx
[19:23:20] <Wes George> just let me know with mic:
[19:23:20] <SwedeMike> wesgeorge: yes. Url to presentations?
[19:23:24] <Wes George> standby
[19:23:28] Dan Wing joins the room
[19:23:31] <jochen.koegel> https://datatracker.ietf.org/meeting/86/materials.html#wg-behave
[19:23:39] <SwedeMike> thanks
[19:23:45] <Wes George> chair slides http://www.ietf.org/proceedings/86/slides/slides-86-behave-1.pdf
[19:23:48] <Wes George> slide 5
[19:23:50] <Wes George> doc status
[19:24:12] cheshire joins the room
[19:24:20] <Wes George> slide 6
[19:25:01] <Wes George> teemu now presenting http://www.ietf.org/proceedings/86/slides/slides-86-behave-4.pdf
[19:25:17] <Wes George> slide 2
[19:25:19] <SwedeMike> sound is crackling
[19:25:31] <Dan Wing> sound better now?
[19:25:31] Juan Pedro Cerezo joins the room
[19:25:32] <SwedeMike> oki, better.
[19:25:34] <Dan Wing> ok
[19:25:35] <Wes George> he was adjusting mic
[19:25:40] pselkirk joins the room
[19:26:15] <Wes George> slide 3
[19:28:14] <Wes George> slide 4
[19:28:37] <Wes George> slid e5
[19:29:58] <Wes George> slide 6
[19:31:32] <Wes George> simon now presenting http://www.ietf.org/proceedings/86/slides/slides-86-behave-3.pdf
[19:31:35] <Wes George> slide 2
[19:32:59] geir joins the room
[19:34:13] <Wes George> slide 3
[19:35:23] <Wes George> slide 4
[19:36:03] <Wes George> phillip matthews - can the inside and outside realm be the same?
[19:36:05] <Wes George> a: yes
[19:36:57] <Wes George> Now discussing http://www.ietf.org/proceedings/86/slides/slides-86-behave-2.pdf
[19:37:51] <Wes George> slide 2
[19:39:54] <Wes George> slid3
[19:40:34] <Wes George> slide 4
[19:42:01] <Wes George> slide 5
[19:42:51] <Wes George> slide 6
[19:43:39] <Wes George> slide 7
[19:44:28] <SwedeMike> question: what about assured delivery and storage of these messages. How is that handled? if it's UDP both of them, none solve this right?
[19:44:43] <Wes George> stby
[19:44:54] <SwedeMike> also, please ask them to speak closer to mic
[19:45:41] <SwedeMike> now sound is even worse
[19:46:06] <Dan Wing> is it distorted, or is audio simply too quiet?
[19:46:10] <SwedeMike> too quiet
[19:46:13] <Dan Wing> alright
[19:46:24] <SwedeMike> like people are speaking away from mic
[19:46:50] ietfdbh joins the room
[19:47:01] <SwedeMike> mikael abrahamsson
[19:47:40] <ietfdbh> The IETF recommendation for syslog is TLS transport RFC5425?)
[19:48:50] <Wes George> lee howard: why is syslog neede dat all - seems ipfix is better?
[19:48:52] <jochen.koegel> NAT logging with IPFIX/NetFlow is already in place today, not only syslog
[19:48:54] <Wes George> a: instantly readable
[19:49:27] <SwedeMike> now sound is crackling
[19:49:31] <SwedeMike> oki, gone again
[19:49:32] <jochen.koegel> IPFIX is more efficient in terms of packet rate. more events per packet....
[19:49:40] <Wes George> dan wing: if packets are lost, device build a queue in mmemory of the packets lost to be retransmiitted - if that queue fills, should we stop doing nat bindings? no
[19:50:10] <SwedeMike> sound is ok now again
[19:50:14] <Wes George> the lavalier (lapel) mics are wired here, so if the speaker moves, it tends to result in some crackling
[19:50:19] <SwedeMike> check.
[19:50:22] <jochen.koegel> From what I know with NAT devices they send log bursts as high as they can create new sessions
[19:50:32] <Wes George> we had one yesterday that if you didn't stand totally still, it'd start a 60hz hum and it was LOUD
[19:50:50] <ietfdbh> Syslog woul dbe most useful for limited data trabsfer; if you want lots of data transferred, then ipfix may be a better choice. Both tools exist as standards for a reason - designed to meet different needs.
[19:51:10] <Wes George> dave do I need to relay that to the mic?
[19:51:17] <ietfdbh> please
[19:51:23] <Wes George> ack
[19:51:31] <jochen.koegel> There are NAT devices that can send 1 Million events/s per NetFlow/IPFIX today....
[19:52:01] <SwedeMike> yeah, a device that does hundreds of thousands of sessions per seconds costs a few 10k USD
[19:52:19] <SwedeMike> (no need to relay my above comment)
[19:56:27] <Wes George> now discussing http://www.ietf.org/proceedings/86/slides/slides-86-behave-0.pdf
[19:56:28] <Wes George> simon
[19:56:38] <Wes George> slide 2
[19:58:12] <Wes George> renaldo - some things also apply to nat64, maybe better to write another draft covering those
[19:58:19] <Wes George> this draft is specific to nat 44
[19:58:34] <Wes George> difficult to manage this in a single document
[20:00:06] <Wes George> phillip matthews - most of the stuff is generic, can be seen to apply to almost any type of nat
[20:00:06] dudisaki joins the room
[20:00:20] <Wes George> remember when we started nat64, most of that stuff came over very easily
[20:00:32] <Wes George> so if we're revising the docs (is this a bis for each doc?)...
[20:00:43] <Wes George> dave thaler: this is an update for the set
[20:01:01] <Wes George> phillip - unless there's a lot that's ipv4-specific, it would make snense to at least try
[20:01:02] <Wes George> slide 3
[20:01:18] <Wes George> slide 4
[20:01:37] <Wes George> slide 5
[20:03:03] <Wes George> slide 6
[20:03:50] <Wes George> slide 7
[20:05:35] <Wes George> stuart cheshire - echoing dave's comments
[20:05:51] <Wes George> lots of things today that run on 443 that aren't web servers
[20:05:55] <Wes George> vpns
[20:06:08] <Wes George> also web servers can be done on !80/443
[20:06:18] <Wes George> renaldo - done on port numbers
[20:06:36] <ietfdbh> Can an attacker take advantage of this to cause confusion?
[20:08:29] <Wes George> renaldo - maybe an opportuntuty to update 4787
[20:08:47] <Wes George> the how of the tweaking also isn't spelled out there
[20:09:14] <Wes George> senthil - is there value in changing from "dont' do this" to "in some circumstances"
[20:09:18] <Wes George> seems we are going backward
[20:09:22] <Wes George> is tehre value?
[20:09:36] <Wes George> simon- value is preserving default (endpoint independent) behavior
[20:09:58] <Wes George> senthil - have to be really careful
[20:10:25] <Wes George> phillip - reason tis is in 4787 is because it's difficult to do nat traversal without this
[20:10:32] <Wes George> but we don't care about nat traversal for things like dns
[20:10:42] <Wes George> vast majority of the cases you want it to be this way
[20:10:52] Tina Tsou joins the room
[20:11:09] <Wes George> stuart cheshire - need to be specific about what you say now about "nat knows..."
[20:11:13] <Wes George> question is how does it know that?
[20:11:30] <Wes George> is this about mapping port nubmers (apps) to timeout times?
[20:11:37] <Wes George> simon - many ways to discover
[20:11:49] <Wes George> stuart- it has to specify or app writers may not know
[20:12:25] <Wes George> those rules (certain porrts, or big packets or small packets) need to be written down
[20:12:36] <Wes George> dave thaler - app won't tnecessarily have control ove rthis
[20:12:44] <Wes George> phillip - what is driving your request to change this?
[20:12:48] <Wes George> a: scalability of port numbers
[20:13:00] <Wes George> if you use one ext port number per 5 tuple, you run out of port numbers
[20:13:06] <Wes George> phillip - other ways to solve - eg dns
[20:13:13] <Wes George> don't send DNS queries throuh the nat
[20:13:17] <Wes George> or time them out faster
[20:13:25] <Wes George> simon - will be stuff goin through the nat, right?
[20:13:50] <Wes George> phillip - have you seen strong demand to do something different like this per application?
[20:13:52] <Wes George> operators?
[20:13:57] <Wes George> simon - recurring topoc
[20:14:12] <Wes George> stuart - EIM is not 1 ext port per 5 tuple
[20:14:24] <Wes George> if it's per 5 tuple, it's endpoint dependent
[20:14:32] <Wes George> it's actually 2 tuple
[20:14:48] <Wes George> one external port per pair, not per 5 tuple
[20:15:03] <Wes George> renaldo - maybe we can just say what is in 4787
[20:15:19] <Wes George> [quoted]
[20:15:25] <Tina Tsou> The voice is low
[20:15:51] <Wes George> dave - that doesnn't match reality
[20:15:58] <Wes George> renaldo - then we need to update 4787
[20:16:12] <Wes George> phillip - different suggestion - sometimes some of these problesm come up because of improper deployment
[20:16:27] <Wes George> maybe wg needs to write a doc with recommended ways to deploy to avboid these problems
[20:16:41] <Wes George> dave thaler - example of unreliable - application is p2p using stun/turn/ice
[20:16:50] <Wes George> I'm double nat, guy I'm talking to is single nat
[20:16:56] <Wes George> his port happens to use porrt 80
[20:17:05] <Wes George> it's not http traffic, but his nat chose this arbitrarily
[20:17:42] <Wes George> slide 8
[20:18:22] <Wes George> phillip - propose that we produce bis versions (not updates, replaceemtnts) for these documents
[20:18:27] <Wes George> star twith those texts and make theupdates
[20:18:33] <Wes George> rateher than making a few changes on top
[20:18:37] <Wes George> that would be cleare
[20:19:55] <ietfdbh> can't hear from here ;-)
[20:20:13] <Wes George> sorry dave, I'm having trouble summarizing the points
[20:20:25] <Wes George> argument between phillip and renaldo about bis vs update
[20:21:01] <Wes George> having to read both docs and diff them is harder than reading one doc
[20:21:08] <Wes George> dan: need volunteers to take on that work
[20:21:14] <Wes George> each of the 3 docs
[20:21:24] <Wes George> phillip - for stun, we rewrote
[20:21:31] <Wes George> this isn't anywhere near the stun update
[20:21:51] <Wes George> dave thaler - as chair - question is first sub-bullet
[20:22:05] <Wes George> if the slides shown are represntative of the doc, both of those issues are not nat44 specific
[20:22:14] <Wes George> issues we've discussed, those apply to nat 64
[20:22:26] <Wes George> no objections to first one, issues with second one
[20:22:36] <Wes George> more of an addendum to the existing
[20:22:54] <Wes George> which may lead to an update rather than a bis
[20:23:08] <Wes George> iuf theres something that's really broken, then let's focus on that
[20:23:18] <Wes George> no consensus on things broken, jst things to add
[20:23:32] <Wes George> other docs are now normatively referencing these RFCS
[20:23:37] <Wes George> some benefit in not obsoleting them
[20:23:41] <Wes George> won't break those refrences
[20:23:44] Tina Tsou leaves the room
[20:24:13] jochen.koegel leaves the room
[20:24:24] <Wes George> dan - does seem interest in updating old specs
[20:24:27] <Wes George> chairs need to discuss
[20:24:41] <Wes George> would need volulnteers, quesiton of wher ethe text goes
[20:24:49] <Wes George> need to hold off on adoption
[20:25:12] <Wes George> volunteers for tcp, udp, and icmp requirements spec - email behave-chairs@tools.ietf.org
[20:25:46] <Wes George> now discussing http://www.ietf.org/proceedings/86/slides/slides-86-behave-5.pdf
[20:26:11] <Wes George> slide 2
[20:26:27] Tina Tsou joins the room
[20:27:54] <Wes George> slide 3
[20:29:01] <Wes George> slide 4
[20:29:17] <Wes George> slide 5
[20:29:57] <Wes George> slide 6
[20:31:00] <Wes George> slide 7
[20:31:18] <Wes George> slide 8
[20:32:50] <Wes George> slide 9
[20:33:46] <Wes George> slide 10
[20:34:13] ietfdbh leaves the room
[20:39:21] geir leaves the room
[20:40:25] Dan Wing leaves the room
[20:42:37] pselkirk leaves the room
[20:44:25] Dan Wing joins the room
[20:44:50] Dan Wing leaves the room
[21:20:38] Juan Pedro Cerezo leaves the room