[04:50:12] --- brabson has joined
[04:50:18] --- brabson has left
[04:52:16] --- Miao Fuyou has joined
[04:52:22] --- Miao Fuyou has left
[06:00:52] --- tsavo_work@jabber.org/Meebo has joined
[06:44:31] --- tsavo_work@jabber.org/Meebo has left: Logged out
[07:10:26] --- jariarkko has joined
[07:48:29] --- Rob @ IETF68 has joined
[07:48:35] --- Rob @ IETF68 is now known as rhe
[07:58:50] --- jariarkko has left
[07:59:23] --- tsavo_work@jabber.org/Meebo has joined
[08:03:22] --- Suzanne has joined
[08:04:14] <tsavo_work@jabber.org/Meebo> could speaker speak closer to microphone?
[08:05:23] --- sam-xzq has joined
[08:05:49] --- fenton@jabber.org has joined
[08:06:58] --- fenton@jabber.org has left
[08:07:09] --- brabson has joined
[08:07:16] --- fenton has joined
[08:07:48] --- shep has joined
[08:12:06] --- miaofuyou has joined
[08:15:38] <shep> which way is a "positive" here?
[08:16:50] <fenton> Good question. I'm assuming that a spoofed packet is a positive
[08:17:28] --- hartmans@jis.mit.edu/owl has joined
[08:18:13] <shep> Ugh, I'm still not sure what he means by "positive" and "negative".
[08:19:19] <shep> Naturally, I would think that "positive" would mean valid source address, but he seems to be using "positive" to mean "spoofed".
[08:19:22] <hartmans@jis.mit.edu/owl> Is this an area where IETF wants to get involved in regulatory enablement?
[08:21:14] --- jakob has joined
[08:21:47] <miaofuyou> I think false positive/negative are borrowed from intrusion detection terminology
[08:22:04] <fenton> Sam, if the only reason to do this was regulatory, that would be an issue. But it's useful for other reasons too.
[08:23:39] --- rbrabson has joined
[08:25:12] --- dumdidum has joined
[08:27:46] --- lars.eggert@googlemail.com has joined
[08:29:21] --- ks has joined
[08:31:01] <shep> Is it the whole IPv6 address that must be verified as legitimate, or just some prefix of it? (In general, in the stuff being discussed in this BOF.)
[08:31:01] --- brabson has left: Lost connection
[08:31:01] --- sam-xzq has left: Lost connection
[08:31:33] --- patchvonbraun has joined
[08:31:48] --- rbrabson has left
[08:32:06] <lars.eggert@googlemail.com> is this the inverse of the evil bit?
[08:32:07] --- rbrabson has joined
[08:35:27] <shep> lars--- not exactly, but your question does suggest one possible implementation of this, a "source adddress valid" bit in the IP header.
[08:37:36] <lars.eggert@googlemail.com> shep: yep, and it comes with all the problems of the evil bit
[08:37:49] <lars.eggert@googlemail.com> (who gets to set it, how do you know it's valid, etc.)
[08:38:49] <shep> instead of having an evil bit, a source address valid bit, etc... we should have a field of a few bits (say 4), and we can then define code points for this field.
[08:39:01] <shep> What should this field be called?
[08:39:19] <lars.eggert@googlemail.com> attitude field?
[08:39:47] <shep> perhaps "intent" field?
[08:42:26] --- sam-xzq has joined
[08:43:11] --- fparent@jabber.org has joined
[08:43:26] --- rbrabson has left
[08:43:55] --- rbrabson has joined
[08:46:27] --- Stephen Farrell has joined
[08:46:49] <hartmans@jis.mit.edu/owl> I'm concerned that this will significant reduce interoperability on the internet.
[08:47:01] --- lars.eggert@googlemail.com has left: Lost connection
[08:47:10] --- jpc has joined
[08:47:17] --- rbrabson has left
[08:47:52] --- rbrabson has joined
[08:48:10] <shep> hartmans--- more so than NATs and security firewalls have?
[08:48:30] --- fparent@jabber.org has left
[08:48:32] <hartmans@jis.mit.edu/owl> Yes.
[08:48:34] --- petri.jokela has joined
[08:50:18] --- rbrabson has left
[08:50:29] --- brabson has joined
[08:51:10] --- lars.eggert@googlemail.com has joined
[08:52:51] --- lars.eggert@googlemail.com has left
[08:53:22] --- fenton has left
[08:54:06] --- lars.eggert@googlemail.com has joined
[08:55:34] --- fenton has joined
[08:56:23] <lars.eggert@googlemail.com> skip it
[08:57:39] <lars.eggert@googlemail.com> have people seen this? http://spoofer.csail.mit.edu/summary.php
[08:58:06] <shep> "not deniable" that's a very strong requirement.
[08:58:34] --- andrewdmcgregor@jabber.psg.com has joined
[09:00:35] --- petri.jokela has left
[09:00:35] <shep> again, this part of talk should be skipped
[09:00:47] --- rono has joined
[09:00:55] <fenton> it's more relevant than the earlier speakers intros
[09:01:24] <shep> yeah, just now noticing that
[09:01:59] <andrewdmcgregor@jabber.psg.com> Economy of backtracking... that might be the key win for SAVA
[09:02:19] <shep> "Problem description" slide, doesn't actually say what the real problem is that needs to be solved.
[09:03:37] <fenton> We have talked about the motivation a lot, but is there a proposal for what gets added to the packet? Non-evil bit, or something more?
[09:05:45] <lars.eggert@googlemail.com> a non-evil hash
[09:06:23] <shep> hmm, a hop-by-hop "i vouch for the the source address in this packet" bit might be enough. But not clear how useful it would be.
[09:06:52] <lars.eggert@googlemail.com> if the act of forwarding would bestow that trust, you wouldn't need to burn a bit
[09:07:11] <fenton> So really a layer-2 thing?
[09:07:20] <hartmans@jis.mit.edu/owl> I really like the idea of the four-bit code field. . . :-)
[09:08:43] --- townsley@jabber.psg.com has joined
[09:09:47] <shep> will four bits be enough for the "intent" field?
[09:10:07] <lars.eggert@googlemail.com> well...
[09:10:12] --- jakob has left
[09:10:26] <shep> lars--- good point about not needing to burn a bit.
[09:10:55] <lars.eggert@googlemail.com> one bit for "non-evil", one bit for "non-evil bit is spoofed", etc. :-)
[09:12:42] <lars.eggert@googlemail.com> shep: that's sort of what bcp38 is doing, right? you don't forward what you don't trust, based on what you locally know
[09:12:47] --- patchvonbraun has left
[09:13:27] <shep> well, the discussion in this bof seems to be that you want to pass along whether or not the address is spoofed so that someone later along the path can apply their policies.
[09:13:28] --- dumdidum has left: Lost connection
[09:13:28] --- ks has left: Lost connection
[09:13:28] --- tsavo_work@jabber.org/Meebo has left: Lost connection
[09:13:28] --- fenton has left: Lost connection
[09:13:28] --- rono has left: Lost connection
[09:13:28] --- Stephen Farrell has left: Lost connection
[09:13:28] --- brabson has left: Lost connection
[09:13:40] <lars.eggert@googlemail.com> right
[09:13:45] --- Stephen Farrell has joined
[09:14:03] --- dward@jabber.org has joined
[09:14:04] <andrewdmcgregor@jabber.psg.com> You know, as an operator, I'd be highly tempted not to trust that information
[09:14:25] <andrewdmcgregor@jabber.psg.com> So there's still the issue of how you make indication of spoofing trustabel.
[09:15:41] <lars.eggert@googlemail.com> andrew: right, because when _you_ drop based on false remote tagging, it's _your_ company that gets the tech support calls
[09:15:52] --- brabson has joined
[09:16:17] <lars.eggert@googlemail.com> which is probably more costly than just forwarding stuff
[09:16:21] <andrewdmcgregor@jabber.psg.com> Yep, exactly.
[09:16:35] <andrewdmcgregor@jabber.psg.com> Not forwarding locally spoofed traffic saves me money though.
[09:16:41] <shep> the major cost of stuff like this is the tech support calls
[09:17:03] <andrewdmcgregor@jabber.psg.com> (especially when it leaves the country, 'cause where I come from international bandwidth is SERIOUSLY expensive)
[09:17:32] <andrewdmcgregor@jabber.psg.com> shep: not necessarily
[09:17:46] --- sulrich has joined
[09:18:01] --- sulrich has left
[09:18:48] --- dward@jabber.org has left
[09:21:54] --- tsavo_work@jabber.org/Meebo has joined
[09:23:16] --- Suzanne has left
[09:30:50] --- stjepan.gros has joined
[09:31:20] --- fenton has joined
[09:33:07] --- stjepan.gros has left
[09:39:01] --- peetu has joined
[09:40:03] --- shep has left
[09:41:38] <townsley@jabber.psg.com> I agree Bob - while most of the time BoFs have a hard time staying focused on the Problem and diving too deep into the solutions, this one seems to be too far in the other direction.
[09:41:52] --- dumdidum has joined
[09:42:25] <lars.eggert@googlemail.com> mark: wasn't there another presentation on the solution that they haven't shown yet?
[09:43:13] --- rono has joined
[09:43:16] <townsley@jabber.psg.com> Only commenting on what we have seen.
[09:46:48] --- rcallon has joined
[09:47:35] --- brabson has left: Replaced by new connection
[09:47:49] --- brabson has joined
[09:49:17] --- ShoichiSakane has joined
[09:51:07] <townsley@jabber.psg.com> Danny Mcpherson says:
[09:51:14] <townsley@jabber.psg.com> 2.16% of attacks emoployed bogon/rfc1918 spoofing over last 6 mo across 31 ISPs, 181k attacks
[09:53:40] --- rono has left
[09:57:40] --- brabson has left
[09:58:31] --- ShoichiSakane has left
[09:58:35] --- Stephen Farrell has left: Computer went to sleep
[09:59:00] --- fenton has left
[09:59:20] --- sam-xzq has left
[09:59:35] --- rcallon has left
[10:00:07] --- miaofuyou has left
[10:00:07] --- townsley@jabber.psg.com has left
[10:00:57] --- lars.eggert@googlemail.com has left
[10:00:59] --- tsavo_work@jabber.org/Meebo has left
[10:02:05] --- andrewdmcgregor@jabber.psg.com has left
[10:02:16] --- rhe has left
[10:11:33] --- dumdidum has left
[10:20:47] --- Stephen Farrell has joined
[10:20:56] --- Stephen Farrell has left
[10:21:34] --- peetu has left: Replaced by new connection
[10:37:44] --- Suzanne has joined
[10:38:56] --- Suzanne has left
[10:44:21] --- elwynd has joined
[10:44:22] --- elwynd has left
[12:24:01] --- jpc has left
[18:00:54] --- miaofuyou has joined
[18:01:44] --- johnson has joined
[18:07:02] --- johnson has left
[18:08:44] --- miaofuyou has left
[18:09:04] --- johnson has joined
[18:09:55] --- johnson has left