[13:41:58] --- jheffner@psc.edu has joined
[13:46:13] --- jheffner@psc.edu has left
[16:14:31] --- nm has joined
[16:15:19] --- nm has left
[16:18:26] --- rhe has joined
[16:20:17] --- becarpenter has joined
[16:20:22] --- frodek has joined
[16:21:46] * becarpenter has changed the subject to: Internet Area Open Meeting 23-Jul-2007
[16:23:12] --- dthaler has joined
[16:23:31] --- terry has joined
[16:23:50] --- philshere has joined
[16:23:52] --- iljitsch has joined
[16:24:40] --- dthaler has left
[16:24:45] --- dthaler has joined
[16:25:51] <iljitsch> brian: you can also use your gmail address for jabber. :-)
[16:28:21] --- mccap has joined
[16:28:49] --- David Martin has joined
[16:29:30] <dthaler> Proposed bofs: SAVA and CGAEXT working towards vancouver, MANEMO discussed in autoconf today, DDOS discussed in this meeting
[16:29:42] --- itojun has joined
[16:30:05] --- behcet.sarikaya has joined
[16:30:12] <dthaler> MIP6/NEMO/MONAMI6 to be merged, IPv6 WG concluding
[16:30:31] <philshere> dnsext going dormant
[16:30:34] <philshere> charter changing
[16:30:56] <philshere> olafur will be the chair
[16:31:02] <mccap> Slides are here: https://datatracker.ietf.org/meeting/69/materials.html
[16:31:08] <philshere> trill meeting for 4.5 miles this week
[16:31:22] <philshere> 6lowpan has finished chartered items, rechartering
[16:31:55] <philshere> mrw: congrat dnsext wg chairs reaching point when they can go dormant
[16:32:25] <dthaler> SAVA slides at http://www3.ietf.org/proceedings/07jul/slides/intarea-1.ppt
[16:32:48] --- elwynd has joined
[16:33:07] <philshere> 3 levels in the sava hierarchy
[16:33:24] <philshere> 1st level is gaining trust in the source address on the first hop
[16:33:35] <philshere> 2nd level is intra domain
[16:33:45] --- dudi has joined
[16:33:46] <philshere> 3rd level is trust between AS/Domain
[16:34:37] --- arifumi has joined
[16:34:43] --- cpignata has joined
[16:34:56] <philshere> 2 kinds of trust, either host-level granularity or address range granularity
[16:35:09] --- sam-xzq has joined
[16:35:21] <philshere> SAVA is about increasing the # of pkts for which you can say I know that's not spoofed
[16:35:57] --- avri has joined
[16:36:42] <philshere> Aim of SAVA is to get as many packets as possible into the strict host-level granularity of trust
[16:36:47] --- apetrescu has joined
[16:37:03] <philshere> near term is focussing on the first hop, none particularly difficult but all have to be documented
[16:37:23] <philshere> several drafts on local subnet methods
[16:39:57] <philshere> more detailed slides for SAVA ML tonight
[16:40:26] <dthaler> next presentation's slides are at http://www3.ietf.org/proceedings/07jul/slides/intarea-3.pdf
[16:40:56] <philshere> discussion of topic of interest from the dhc working group
[16:41:21] <philshere> dhc received a proposal for subscriber authentication wrt DSL deployments
[16:41:28] <philshere> draft-pruss-dhcp-auth-dsl
[16:41:47] <philshere> may be other solutions besides dhc, so needed int area review of problem space
[16:42:11] <philshere> dsl forum sent some liaisons
[16:42:32] <philshere> liaison includes set of requirements
[16:42:57] <philshere> replace PPP with IP only architecture
[16:43:18] <philshere> requires replacement for ppp session
[16:43:28] <philshere> needs subscriber authentication as part of session mgmt
[16:43:43] <philshere> discussion will take place on int-area@ietf.org
[16:43:52] <philshere> issue will be revisited at ietf 70
[16:44:04] <apetrescu> Allison MAnkin is that?
[16:44:04] <philshere> allison: what happened to dhcp server authentication?
[16:44:32] <philshere> ralph: had auth for some time but what is in rfc 3318 didn't meet reqts of dsl
[16:44:36] <philshere> forum sub authentication
[16:44:41] --- iljitsch has left
[16:44:44] <philshere> allison: what about doing server authentication
[16:44:54] <philshere> ralph: bring it up in dhc working group
[16:45:09] --- nm has joined
[16:46:10] <dthaler> next presentation's slides are at http://www3.ietf.org/proceedings/07jul/slides/intarea-6.pdf
[16:46:54] --- cabo has joined
[16:47:10] --- apetrescu has left
[16:49:17] --- batfli has joined
[16:49:28] --- batfli has left
[16:50:13] --- RicPruss has joined
[16:50:20] <philshere> big packet advantages
[16:50:29] --- alexpetrescu has joined
[16:50:29] <philshere> more room for addl hdrs without mtu breakage
[16:50:35] <philshere> lower overhead with large headers
[16:50:42] <philshere> less per packet work in hosts
[16:50:52] <philshere> less per packet in routers
[16:50:58] <philshere> better tcp performance
[16:51:33] --- fp has joined
[16:51:49] <philshere> devices are available that support this in hardware
[16:52:02] <philshere> common value of jumboframes is +/-9000, but no standard
[16:52:14] <philshere> mini jumbos available at +/-2000
[16:52:21] <philshere> disadvantages
[16:52:28] <philshere> more delay and jitter
[16:52:41] <philshere> only do 1500+ at gb or faster
[16:52:48] <philshere> depend more on path mtu discovery
[16:52:59] --- PasiS has joined
[16:54:18] <philshere> more disadvantages
[16:54:25] <philshere> more pkt loss from bit errors
[16:54:35] <philshere> can calc opt packet size
[16:54:40] --- RicPruss has left
[16:54:44] <philshere> more undetected bit errors?
[16:55:03] <philshere> maybe use stronger fcs for jumboframes
[16:56:23] <philshere> proposed soln
[16:56:37] <philshere> 1) remove limitation that all nodes on subnet use the same MTU size
[16:56:44] <philshere> use standard MTU as default
[16:56:53] <philshere> negotiate per-neighbor MTU (and test)
[16:57:03] <philshere> 2) hw vendors must implement reasonable hardware MTUs
[16:57:10] <philshere> admins may override at any point
[16:57:35] <philshere> the protocol:
[16:57:45] <philshere> learn v6 neighb MTU from neighbor disc
[16:57:47] <philshere> send test pket
[16:57:58] <philshere> ignore TCP MSS option and subnet MTU and use neighbor MTU
[16:58:05] <philshere> IPv4 same but different
[16:58:13] <philshere> Qs?
[16:58:44] <philshere> itojun: similar problem with Mac and would like to solve
[16:58:57] <philshere> I think it is difficult for us to update ND option
[16:59:09] <philshere> may want to implement something within l2 devices
[16:59:19] <philshere> ivB: why?
[16:59:26] <philshere> itojun: too late to update ND
[16:59:32] <philshere> ivB: don't understand
[16:59:42] <philshere> itojun: replace v6 devices that are already deployed
[16:59:50] <philshere> ivB: add option if you want to implement
[17:00:25] --- rdroms@gmail.com has joined
[17:00:40] <itojun> but in reality people use non-updated ND with 9000bytes MTU...
[17:00:49] <itojun> (itojun, btw)
[17:01:03] --- rdroms@gmail.com has left
[17:01:03] <philshere> there is an RFC from the transport area that talks about how to do this
[17:01:21] <philshere> dthaler: don't think it requires new ND options
[17:01:30] <philshere> 2461 allows path MTU discovery to work in this situation
[17:01:34] --- RalphD has joined
[17:01:35] <philshere> no changes to host needed
[17:01:47] <philshere> as long as host believes its own MTU is max
[17:01:54] <philshere> quotes MTU option from RFC
[17:02:03] <alexpetrescu> PMTU from rfc2461
[17:02:38] <philshere> tim shepherd:
[17:02:50] <philshere> RFC publishes in last few weeks about packetization layer path MTU discovery
[17:02:55] <philshere> problem is not solved
[17:03:06] <philshere> don't know about a cloud of ethernet switches
[17:03:16] <philshere> problem is there might be an ethernet link in the middle
[17:03:19] <itojun> RFC2461 page 32
[17:03:36] <philshere> new packetization layer mtu discovery TCP will do the right thing
[17:03:50] <philshere> but it's still quite tricky and there are still some problems to be solved
[17:03:53] <philshere> don't need a new protocol
[17:03:54] <cabo> rfc4821
[17:04:04] <philshere> send jumbo discovery pkts
[17:04:14] <philshere> need a document that explains the problems and how to solve them
[17:04:51] <philshere> ivB: want to avoid switches receiving tons of pkts when they can't deal with them
[17:04:56] <philshere> some security issue
[17:04:57] <philshere> ?
[17:05:13] <philshere> take it offline and see which approach is conservative enough
[17:05:30] <philshere> tim shepherd: probe for path MTU the same way you probe for congestion state
[17:05:40] <philshere> start with small packets
[17:05:49] <philshere> after a few round trips, try throwing in a large packet
[17:06:00] <philshere> can detect from the acks then
[17:06:09] <philshere> 9K is not big enough
[17:06:22] <philshere> 30,40, or 50KB packets should be sendable
[17:06:31] <philshere> have matt mathis and company take a look
[17:06:53] <philshere> fred templin: the treatment of the packet size and crc is an important contribution
[17:06:57] <philshere> what about tunnels?
[17:07:14] <philshere> ivB: wouldn't know
[17:07:51] <philshere> nordmark: useful to write down the missing pieces
[17:07:55] <philshere> given that we have tcp work
[17:08:05] <philshere> what needs to happen at IP level to make the pieces fit together?
[17:08:16] <philshere> how do you want to discover stuff?
[17:08:23] <philshere> those are the ?s we should go look at
[17:08:29] <philshere> tricky to deal with IEEE
[17:08:46] <philshere> hard to convince them to send an error message back when the packet is too big
[17:08:50] <philshere> mostly implementation stuff
[17:08:58] <philshere> who is that guy?
[17:09:12] --- narten has joined
[17:09:28] --- PasiS has left: Replaced by new connection
[17:09:35] <philshere> aboba: IEEE is perfectly willing to work together with IETF to produce something
[17:09:43] <philshere> if someone on our side is interested, we could do it
[17:09:58] <philshere> dthaler: agree with Tim and Erik to have a document that is informative to clarify issues
[17:10:48] <philshere> lots of discussions since Prague
[17:10:58] <philshere> 800 messages on RAM with @500 subs
[17:11:11] <philshere> 400 messages on RRG ML with 184 subs
[17:11:21] <philshere> RAM@iab.org
[17:11:25] <philshere> RRG@psg.com
[17:11:55] <philshere> brief list on work that has been done
[17:11:59] <philshere> design goal doc
[17:12:07] <philshere> various proposed designs (5 listed)
[17:12:21] <philshere> study on the cost of mappings caching and mappings lookup
[17:12:32] <dthaler> (actually 4-6 depending on how you count them :)
[17:12:53] <philshere> calls attention to rrg meeting this Friday AM from 9am-5pm
[17:13:04] --- avri has left
[17:13:45] <philshere> mark handley on ddos attacks
[17:13:48] <dthaler> http://www3.ietf.org/proceedings/07jul/slides/intarea-2.ppt
[17:14:31] <philshere> whether there is anything the IETF should do about them?
[17:14:36] <philshere> audience member: No!
[17:14:41] <philshere> (laughter)
[17:15:05] <philshere> didn't foresee this problem in the internet architecture
[17:15:20] <philshere> Can the IETF do anything?
[17:15:28] <philshere> Does anyone care to spend enough money on solutions?
[17:15:33] --- iljitsch has joined
[17:16:01] <philshere> No shortage of solutions - 7590 papers on this using Google scholar
[17:16:08] <philshere> no magic bullet
[17:16:26] <dthaler> but how many of those are false hits resulting from someone DDoSing you to hide the true solution ;-)
[17:16:27] <philshere> DDos is not like getting compromised
[17:16:42] --- PasiS has joined
[17:16:46] <philshere> Goal should be to raise the bar for successful attacks
[17:17:12] --- harald has joined
[17:17:17] <philshere> Don't necessarily need a magic bullet
[17:17:23] <philshere> examples of raising the bar:
[17:17:36] <philshere> require more firepower for a successful attack
[17:18:00] <philshere> prevent spoofing
[17:18:05] <philshere> enforce congestion control
[17:18:15] <philshere> provide automated filtering of flows at the source
[17:18:51] --- oak has joined
[17:20:14] <philshere> Goal for IETF?
[17:20:30] <philshere> Force an attacker to make his traffic indistinguishable from a flash crowd
[17:20:34] <philshere> move the attack up the stack
[17:20:54] <philshere> different apps then tackle the problem using their own application specific mechanisms
[17:21:05] --- cpignata has left
[17:21:05] --- cpignata has joined
[17:21:39] <philshere> Then is anyone willing to pay?
[17:21:54] <philshere> depends on who has to pay, and how much they have to pay
[17:22:02] <philshere> hope is people who have to pay get benefit from it
[17:22:13] <philshere> for the victims: DDos is very expensive
[17:22:34] --- cpignata has left: Logging off
[17:23:05] <philshere> for source ISPs, fairly significant costs
[17:23:30] <philshere> chris from verizon: what is considered lower bandwidth?
[17:23:46] <philshere> mh: in the range of a few Gbs, but not a lot above that
[17:23:58] <philshere> mh: what is the cost?
[17:24:15] <philshere> chris: $32.50/mo
[17:24:21] <philshere> www.verizonbusiness.com
[17:24:57] <philshere> mh: don't believe scrubbing solns are the right universal soln for the Internet
[17:25:01] --- itojun has left
[17:25:26] <philshere> can't imagine every single flow on the Internet going through the scrubbing
[17:25:35] <philshere> Chris: dealing with live attacks every day for 8 years
[17:25:44] <philshere> there are lots of solutions available
[17:25:51] <philshere> if you're ISP can't find a solution we can
[17:25:54] <philshere> (laughter)
[17:25:59] <philshere> no silver bullet
[17:26:04] <philshere> point solutions are effective
[17:26:19] <philshere> mh: not solving the route cause
[17:26:31] <philshere> Sam hartman: a 1-5 sentence defintion of scrubbing
[17:26:43] <philshere> chris: at some place it begins being app level filtering
[17:27:02] <philshere> mh: redirect traffic to the victim to a box that determines which is good/bad
[17:27:25] <philshere> mh: also support costs on the ISP of the sender
[17:28:10] <philshere> transit ISPs- often just more paying packets
[17:28:20] <philshere> people willing to pay are at the edges of the network
[17:28:33] <philshere> there are also opportunity costs
[17:28:44] <philshere> ever increasing demand being placed on the internet
[17:28:52] <philshere> options:
[17:29:03] <philshere> internet gets robust enough to justify tehse demands
[17:29:15] <philshere> demand met by parallel networks ar increased cost
[17:29:42] <philshere> a lrage well resourced Ddos will cause huge economic damage
[17:30:27] <philshere> need to pick one, I recommend the first
[17:30:47] <philshere> we should solve the problem before lawmakers involve themselves
[17:31:02] <philshere> don't produce medicine that is worse than disease
[17:31:06] --- FDupont has joined
[17:31:12] <philshere> architectural ossification is a problem
[17:32:31] <philshere> big challenge is to mitigate DDos attacks without sacrificing the future
[17:32:50] <philshere> future: intelligent network that understands and controls bad traffic
[17:33:07] <philshere> operators define and control policy for different classes of traffic
[17:33:07] --- becarpenter has left
[17:33:08] --- becarpenter has joined
[17:33:09] --- becarpenter has left
[17:33:40] <philshere> are there other ways to change the internet architecture?
[17:34:04] <philshere> can we do it and preserve the general nature of the Internet to allow future innovation?
[17:34:11] <philshere> two apps:
[17:34:21] <philshere> automated filtering framework: terminus
[17:34:41] <philshere> improved congestion management framework: re-feedback
[17:35:46] <philshere> terminus: detect attack at destination and filter at source
[17:36:00] <philshere> bunch of boxes in terminus architecture on slide
[17:37:21] <philshere> - need to know real origin of attack packets
[17:37:37] <philshere> - add a true-source bit to packets
[17:37:48] <dthaler> (not to mention that the slide shown just opens a different DOS vector, since the "please filter traffic" could come from an attacker to stop a legit stream)
[17:39:11] <iljitsch> so the end requesting filtering must make sure the packets come from where they claim to be coming and the end that is going to filter must ake sure the request to filter comes from where it claims to be coming from....
[17:39:41] <iljitsch> (assuming the filtering will happen on source/dest combinations, not just source address)
[17:39:54] <philshere> lots of additional details
[17:40:05] <philshere> point here is that this is the kind of mechanism the IETF could use
[17:40:49] --- harald has left
[17:43:01] --- RalphD has left
[17:44:21] --- elwynd has left: Replaced by new connection
[17:44:21] --- elwynd has joined
[17:44:21] --- elwynd has left
[17:44:38] --- elwynd has joined
[17:44:38] <philshere> why IETF should do something
[17:44:42] <philshere> - who else will?
[17:44:49] <philshere> effective solutions require protocol changes
[17:44:58] <philshere> doing nothing is worse
[17:45:25] --- mccap has left
[17:45:31] <philshere> jc from neustar: IETF is not the best place
[17:45:43] <philshere> NANOG or RIPE or something to see what kind of feedback you get
[17:45:56] <dthaler> (back to iljitsch's summary above "so the end...", it's not just that, it also has to be the case that the requester is authorized to do so. I mean an attacker who doesn't spoof his request to filter someone else's traffic still alows the source end to know it comes from where it comes from, but it's just a bot)
[17:45:57] <philshere> am skeptical about how well something like this will work
[17:46:36] --- harald has joined
[17:46:59] <philshere> greg daley: customers are getting hurt by DDoS
[17:47:07] <philshere> disagree with some analysis about spoofing
[17:47:19] <philshere> there are sufficient hosts on network that are compromised
[17:47:33] <philshere> so to prevent spoofing is an inappropriate use of resources
[17:47:49] <philshere> mh: not just anti-spoofing by themselves is useful
[17:48:11] <philshere> gd: problem is when does problem at recipient become the origin network's problem?
[17:48:24] <philshere> not going to do that easily without many years of work to understand
[17:48:31] <philshere> it's research now, not engineering
[17:49:17] <philshere> IETF focus should be on things closer to where the problem is going
[17:49:39] <philshere> lixia: at high level, I support what Mark said
[17:49:59] <philshere> lixia: have done some recent work in combination with new design of routing system
[17:51:33] <dthaler> Geoff's slides at http://www3.ietf.org/proceedings/07jul/slides/intarea-7.ppt
[17:51:51] --- arifumi has left
[17:52:06] <philshere> about 3/4s of addresses are used in rough terms
[17:52:42] <dthaler> 3/4s of the /8 prefixes are allocated by IANA to RIRs that is
[17:52:52] --- arifumi has joined
[17:56:22] --- dudi has left
[17:57:17] --- shep has joined
[17:57:25] --- harald has left
[17:57:37] <shep> http://www.xkcd.com/195/
[17:58:09] --- PasiS has left
[18:02:27] --- nm has left: Replaced by new connection
[18:02:28] --- nm has joined
[18:02:28] --- nm has left
[18:03:10] --- rhe has left
[18:04:00] --- narten has left
[18:08:15] --- behcet.sarikaya has left
[18:09:50] --- arifumi has left
[18:11:25] --- shep has left
[18:11:27] <philshere> summary: ipv4 addresses exhausted in 3 years
[18:12:21] <philshere> greg daley: read article online about conjectural mechanisms to claim unadvertised address space
[18:12:25] <philshere> any ideas aobut that?
[18:12:32] <philshere> GH: me personally
[18:13:23] <philshere> narten: too little, too late
[18:13:32] <philshere> narten: what if we squeeze here, what about the reserved space
[18:13:38] <philshere> light at the end of the tunnel is there
[18:13:42] <philshere> gh: agreed
[18:13:59] <philshere> tim: get v4 allocation now
[18:14:15] <philshere> model changes every 3 or 4 months
[18:14:26] <philshere> hard to predict when the panic buying will happen
[18:14:36] <philshere> gh: have been looking at this model for 5 years
[18:14:44] <philshere> date keeps getting closer and closer
[18:14:46] --- arifumi has joined
[18:14:55] <philshere> gh: already see some signs of folk doing things
[18:15:12] <philshere> gh: all based on public data
[18:15:17] <philshere> ipv4.potaroo.net
[18:15:47] --- shep has joined
[18:15:58] <philshere> ivB: . . . .
[18:16:14] <philshere> ivB: burn through 20 /8s per year will only buy you a year and a half or something
[18:16:28] <philshere> sam hartman: tim said an important fallacy to avoid
[18:16:35] <philshere> sh: get your addresses now
[18:16:38] --- arifumi has left
[18:16:50] <philshere> sh: that's not what geoff or the data says, unallocated addresses will run out in a few years
[18:17:00] <philshere> sh: transition from an open market to a closed market
[18:17:09] <philshere> sh: addresses will cost you more, maybe a lot
[18:17:17] <philshere> sh: and think about the dynamics of that
[18:17:40] <iljitsch> what I said was: reclaiming legacy address space will only buy you a year and a half or something like that if we are going to burn through 20 /8s per year soon
[18:18:06] <philshere> james ?:
[18:18:24] <philshere> yes, markets are good at finding the optimum price at which a commodity will clear
[18:18:43] <philshere> price of ip addresses could rise to be high
[18:18:56] --- alexpetrescu has left: Replaced by new connection
[18:18:57] <philshere> internet society might find it a good idea to hand out to charitable organizations
[18:19:34] <philshere> (audience) why doesn't apple donate some?
[18:19:59] --- sam-xzq has left: Replaced by new connection
[18:19:59] --- sam-xzq has joined
[18:19:59] --- sam-xzq has left
[18:20:02] <philshere> tj kniveton: do you have a graph of how the date has changed over time?
[18:20:07] <philshere> gh: have data, haven't published
[18:20:19] <philshere> gh: as we get accelerating growth demands, the model changes
[18:20:58] --- arifumi has joined
[18:21:20] <philshere> bob hinden: amusing to watch the rate of change of predictions
[18:21:35] <philshere> bh: maybe people will deploy IPv6
[18:21:51] <philshere> maybe a market for folks who switch to v6 and sell their v4
[18:22:00] <philshere> great for developed world and sucks for the rest of the world
[18:22:24] --- iljitsch has left
[18:22:50] --- shep has left
[18:23:00] --- fp has left
[18:23:01] <philshere> alain durand: take exception to Sam
[18:23:09] <philshere> to buy, you need to have someone to sell
[18:24:39] <philshere> marla: thank for redoing the numbers
[18:25:04] <philshere> scope creep - this is RIR policy relevant
[18:25:56] --- arifumi has left
[18:25:58] <philshere> danny: we're going to run out, it's inevitable
[18:26:15] <philshere> IETF transtion mechanisms don't allow us to have a v4 host talk to a v4 dest
[18:26:32] --- philshere has left
[18:29:01] --- David Martin has left
[18:29:01] --- cabo has left
[18:29:46] --- arifumi has joined
[18:30:30] --- FDupont has left
[18:32:27] --- terry has left
[18:33:01] --- arifumi has left
[18:41:58] --- oak has left: Disconnected
[18:45:37] --- elwynd has left
[18:46:31] --- frodek has left
[18:46:49] --- dthaler has left
[18:51:46] --- dthaler has joined
[18:51:51] --- dudi has joined
[18:52:12] --- dthaler has left
[18:52:23] --- harald has joined
[19:08:05] --- harald has left
[19:10:54] --- dudi has left
[19:20:21] --- elwynd has joined
[19:31:00] --- elwynd has left: Replaced by new connection
[19:31:00] --- elwynd has joined
[19:31:00] --- elwynd has left
[21:45:02] --- arifumi has joined
[21:45:13] --- arifumi has left