INTAREA Internet Area Open Meeting MONDAY, July 23rd, 2007 1520-1720 Afternoon Session II Red Lacquer Area Directors: Jari Arkko and Mark Townsley Notes takers: Samita Chakrabarti and Phil Roberts Jabber notes: http://www3.ietf.org/meetings/ietf-logs/intarea/2007-07-23.html Area status update (ADs) BOF situation ============== See slides. Major working group news ======================== * MIP6, NEMO, MONAMI6 will be merged to a new working group called MEXT. Chair selection is under consideration by Jari Arkko. * IPv6 is about to close * SHIM6 - Wg doc to IESG * DNSEXT - going to be dormant * TRILL - A lot of activity * 6Lowpan - First set of documents done; working with routing area for lowpower routing. This will be discussed RTG area meeting on Tuesday. SAVA( Source Address Verification Architecture) framework update: ---------------------------------------------------------------- Now it has three levels - How to gain trust in SRC addr - Intra-domain soruce addr validation - Inter-domain SAVA how to communicate and preserve trust level between administrative domains 2 levels of trust of SRC address defines Strict SAVA Loose SAVA SAVA work is initially focused on first hop - local subnet in enterprise - residential broadband, wireless mobile Focus for rest of 2007 is work towards BOF at Vancuver. Local subnet current work draft-baker-sava-simple-00 draft-wu-sava-solution-firsthop-eap-00 draft-bi-sava-solution-ipv6-edge-network-signature-00 draft-sava-prefix-reachability-detection-00 DHCP wg status (Ralph, Droms) ------------- dhc WG reviewed proposal for subscriber authentication based on DHCP authentication draft-priss-dhcp-auth Consensus in Prague was that there may be other solutions than dhcp. We decided that we needed an internet area review, rather than jumping to the conclusion that dhcp is the solution. We needed a set of requirements from the DSL Forum. DSLF provided those requirements. We received a liasion from DSLF. It is available on te ietf website. DSLF looking to replace PPP with raw IP. One of the requirement is to have ip session management. Session mgmt requires subscriber authentication Internet ADs will kick off discussion in int-area@ietf.org Issue will be revised at IETF 70 Allison M.: What happened to dhcp server authentication in the charter? Ralph: Server auth is an orthogonal issue, bring it up on the dhc wg. Multi-MTU subnets ----------------- draft-van-beijnum-multi-mtu-00 Problem : Ethernet MTU 1500 , Mbps 10MB , 813 pkts/sec Fast ethernet 1500, 100, 8127 I gbit ethernet 1500, 1000, 81274 pkts/sec 10 gbit Ethernet 1500, 10000, 812744 pkts/sec Why still 1500 MTU size? 1500 for last 30 yrs old equipment handles > 1500 badly Big packet advantage - more room for additional headers without MTU discovery breakage - Lower overhead especially with large headers - Less per-packet wrk in host - faster - less per-pkt in rtr - possible power savings Jumboframes characteristics: Common value ~9000 bytes More delay and jitrer Depend more on PMTU More pkt loss due to bit errors Use stronger FCS for jumbo frames? Solution - Remove limitation that all node in network must use same MTU - use standard MTU as default Learn IPv6 MTU from ND option Ignore TCP MSS option Rtr adv option - MTU for diff link speed off-link MTU ? New switch adv ( about supported MTU) Questions for next step ? QA -- concern on backward compatibility ? No. New option will only be valid for new implementation No new ND option rqd. RFC2461 already supports PMTU in router/switches. Packets size and CRC are two diff interaction - good work in this draft. Itojun: i have similar problem. I think it is difficult for us to update the ND option. It's little bit dirty but I want to implement something in L2 devices. Presentor: why is this the case? Itojun: it is a little bit too late. every single IPv6 device needs to be updated? presentor: No, only two ends need to implement. I don't see a problem. unknown: ...speaker: we shall take this off line. Dave thaler: Want to go back to Itojun's comment. i don't think this requires changes to ND. No changes on host needed. 2461 supports this. Tim shepherd: An rfc published on how to do packetization and mtu discovery. works really nice. there is problem about links in the middle. TCP will do the right thing. it is still quite tricky. But it does not require new protocol. I do believe we need a document that explains what the problems are and how to solve them. presentor: we shall take this offline and discuss approaches. which wg is that? Tim: pmtud wg. Tim: start out with small packets. Later throw out a large packet, and go back to smaller packets. Continually probe. Fred Templin: what are the interactions with tunnels? ND may be going across the internet. presentor: I'll think about it. Erik Nordmark: it is useful to write down the missing things. what needs to be done at the IP level. not sure if necessary to do IP level protocols. dealing with ieee is tricky. its mostly implementation stuff a this stage. Bernard: we had multiple discussions with ieee on jumboframes. Dave Thaler: an informative document is good. Routing research group (Lixia Zhang) ----------------------- Many discussions on the list RAM@iab.org : 800+ msgs RRG@psg.com : 400+ msgs rrg-request@psg.com to subscribe Progress toward solution development = draft on design goals Various proposed design RRG meeting Fri 9-5 DDos Attack ---------------- Should IETF do anything about DDos attack ( Mark Handley) ? Does anyone care enough to spend money to provide solutions ? Google search for DDoS : 7590 hits Raising the bar - require more firepower to - prevent spoofing - enforce consestion control - provide automated filtering of flows at the source Goal for IETF - Move attack up the stack ( make it difficult for the attacker to distinguish from a flash crowd) How expensive ? For the victims : DDoS is very expensive For the source ISP; fairly significant cost Transit ISP : Often just more paying pkts -QA ; There are some real-deployment solutions exist which work already Opportunity costs - Internet usage demand is increasing - parallel usage of internet - Successful DDDOs attack will cause huge damage Code is hard to change, how to make it work without too much sacrifice? Intelligent network - network based app recognition -Deep packet inspection -Network administrattive control Architectural solution Two example: - Automated filtering framework Terminus - Identify attack traffic at dst ISP - Block attack traffic at source ISP Preventing spoofing - how to send filter rqst to the true-attacking src Re-feedback Re-architecting of congestion control framework for Internet - charge involved Q/A - chris@verizon: what is the considered lower bandwidth? presentor: few gigabits. Chris: it is just $32.50 per month. Chris: a lot of progress has been made for networks to perform better under stress. Chris: there is no silver bullet security. Chris: some of the solutions exist. rate limiting. filtering. they are effective. Sam Hartman: give me definition of scrubbing. Chris: applicaiton level filtering. unknown: I'm skeptical that this will work. deploying a new protocol is exponentially difficult. Greg Daley: I agree that customers are getting hurt by DDoS. I think there are sufficient devices that are compromised without spoofing. effort into modifying protocols to tackle spoofing is not good. economics of internet requires research. we can do a lot more at where the problems are felt.ietf should focus on where the problems is felt. Lixia: we can leverage on routing mechanisms. IPv4 Consumption status (Geoff Huston) -------------------------------------- Staus of IPv4 addr space today IANA address handout chart (2005+ - explosion of internet address assignment mainly due to broadband allocation of addresses) Advertise addr space has increased too - even some of the address space is not used in practice. IANA-RIR allocation, RIR allocation rates, assigned , unasigned addr pools are considered in the estimation. Jeff showed a number of charts of the above parameters over time. IANA runs out of Ipv4 addresses sometime in Jan 2011 Total address demand is exponentially rising. IANA allocatates the last IPv4/8 address in the coming 3rd year at this rate of allocation. http://ipv4.potaroo.net (for more details) Q/A: Greg Daley: any ideas about unadvertised space? geoff: what used to be an academic issue is now happening. Narten: too little too late. the light at the end of the tunnel is there. we are going to hit it. Tim Chown: there is going to be a significant rush. geoff: the date of exhaustion is getting closer and closer each year. Unknown: dates in my calculations are more conservative. Sam Hartman: get your addresses now, said Tim. But that's not what Geoff said, not what data said. we'll transition from open market to closed market. you'll get your address, it may cost you a lot. Geoff: we'll see. James@apple: markets are good at finding appropriate prices. internet society may find it a good idea to reserve address block for charities. TJ: do you have a graph that shows how the exhaustion date changes? Bob Hinden: it sucks for the non-developed world. if we care about growing the internet who don't have it yet, we need to make sure that we can still talk to them. Alain Durand: in order to buy, there needs to be somebody to sell. unknown: closed markets, etc. this is all very policy related. unknown: we need to revisit the transition solutions. internet area should be looking at this. Greg Daley: we don't have time to work on new transition mechanisms. Narten: if we use addressing more efficiently, we'll see increased routing table sizes.