TUESDAY, March 23, 2010 0900-1130 Morning Session I ------------------------------------- Internet Area Working Group Chairs: Julien Laganier & Christian Vogt These meeting minutes are based on notes taken by Ed Jankiewicz First meeting as a working group Continuing the same work, different organization of forum Work items of interest to the internet area, too small to form a specific working group Jari Arkko Internet of Things, JP Vasseur (40 min) --------------------------------------- “thing” is a smart object, eg. RFID tag, sensor, actuator etc. wide range of size and cost Most cases unattended and constrained devices e.g. Atmel Atmega microcontroller (see picture in slides) the terminology has evolved applications - Smart Grid o the grid is today unidirectional power flow; evolving to bidirectional switching of generation and distribution o Millions of sensor/actuator devices - Smart+Connected Communities o Green field, new capabilities – traffic mgt, lighting, social network organization, etc - The Connected Home o Thousands of devices, home security, power/appliance mgt Research interest Sensor networks, most focus on algorithms RS485 wired sensor/actuators – rather proprietary, collapsed layers, trading flexibility for optimization Non-IP standardized protocols IC101? Why not IP? List of myths - too big, not optimized for constrained environment - insecure, too open - proprietary=secure IP end to end is a must for Internet of things Translation gateways break a lot of stuff, least common denominator Link layer – 802.15.4 assumed to be the only low power link, but others have emerged, incl low power Wifi, Power Line, new RF IP – perfect fit Wide range of devices, media – IP good enough for everything Billions of devices in harsh environments Buildings, lots of legacy protocols to adapt ISA Medical and automotive Scale and stateless autoconfiguration is an advantage for IPv6 ROLL focused on IPv6 Big address field poses some issues Is IP too greedy for constrained devices? microIPv6 stack – IPv6 Ready – very lightweight what’s going on in IETF 6lowpan, ROLL, CORE 6loWPAN adaptation layer – 802.15.4 small MTU Routing – where? Propriety protocols route on MAC address, stitching together different routing “mesh under” and “route over” Complexity, past experience Multilayer recovery overly complex Routing protocols Link failures, constrained space routing Energy major issue, bandwidth, processing power, randomness, harsh environments Very different from ISP networks Convergence time optimized Here we need robustness Routing over Lossy Links RPL – dynamic timers CoRE – first WG meeting Carsten Bormann Number of items to work on 6lowapp was a start Transport, security, discovery Application protocol on constrained networks Like HTTP or SNMP, all have some inappropriate properties Explore architecture coming up with REST HTTP is one REST protocol A new RESTful protocol Constrained RESTful Environment (CoRE) Connectivity Models Autonomous Smart Object Network Internet of things – direct access to things, server access Extended Internet – overlay Plenty to do Application optimization Transport Delay Tolerant Network Lightweight security and privacy Major applications – not just cool technology. Need solution today. Bumpy road so far, working against embedded ideas IPSO alliance promoting the use of IP Christian Vogt – a lot of benefits but challenges Jari Arkko – 3 working groups, existing deployments, IP is the key protocol – not a hard sell. List of things we need on your list – what is the next priority in addition to current WG efforts? JP – CoRE important, lightweight security, privacy Bob Hinden – this is a fast stuff, should not be a problem running IP on it ------------------------------------------------------------------------------ Updated Specification of the IPv4 ID Field, Joe Touch (10 min) ------------------------------------------------------------------------------ http://tools.ietf.org/html/draft-touch-intarea-ipv4-unique-id-03 OR http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-00 recommendations on consistency align with IPv6 ID field issued as an intarea doc requirements language clarified compare IPv4 IPv6 in v4, in all packets, fragmentation everywhere if you honor the requirement to maintain MSL uniqueness, limit to 6.4 Mbps @1.5K this is clearly violated by everyone SHOULD limit fragmentation in IPv4 – to the source, with DF=1, only where safe (no overlapping, no repeating ID, no reordering) add an integrity check Fred Templin – SHOULD? Not a MUST Joe – cat’s out of the bag; integrity check trumps MUST NOT fragment if ID is not unique – bad idea MUST NOT reuse ID if already fragmented MUST NOT use for duplicate detection (RFC 1122) RFC 791 – if retransmitting, can use the same ID, alt path leading to different fragmentation. Constraining to source frag, only network duplication could result in overlapping - MUST ignore overlap fragments. List Issues “maximum jitter” Clarify IPv6 examples, may lead to updating RFC 2460 More Issues How it impacts NATs – acting as host – follow host requirements Broken devices ignoring DF bit – will be more broken Transition plan – if everyone ignores DF bit, ID could cycle faster Christian – high value, small effort work that is ideal for this Intarea WG Eric Nordmark – DNS servers prefer the network fragments (500 bytes) rather than maintain state. Don’t want to set DF=1. Joe – reasons why it should be an exception Fred Templin – note that the SHOULD can never become a MUST Ely? – v4-v6 interaction Joe – as we change the rules for IPv4 hosts, need to change the rules for translation Christian – WGLC is in order? No objection. ------------------------------------------------------------------------------ Tunnels in the Internet Architecture, Joe Touch (10 min) ------------------------------------------------------------------------------ http://tools.ietf.org/html/draft-touch-intarea-tunnels-01 OR http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00.txt Chartered work Avoid reinvention, survey approaches Tunnels are commonly in use Tunnels are layer 2; subject to same design advice Known issues – MTU, fragmentation, performance, packing And various methods to handle them Fragmentation – reassy at egress or dest Signaling inside/outside Draft – core dump, need contributions – please help Additional draft on tunnel security – to remain separate. Fred Templin – also mid-layer fragmentation Alain Durand – please present this at the next Softwire meeting in Maastricht Christian – read, feedback on ML ------------------------------------------------------------------------------ Summary of 3GPP-IETF meeting on IPv6 migration, Fred Baker (10 min) ------------------------------------------------------------------------------ China Mobile invitation Shanghai before IETF 76, and follow-up in SanFran later Tech report from 3GPP Migration and co-existence – discuss current ideas on table Conclusions – based on 3 scenarios After looking at the options, the support is available in the network to turn on IPv6 DSlite and other approaches in behave are applicable IETF next steps – get work in behave advanced A+P IPv4 extension useful 3GPP – timelines often required, left open at this time ------------------------------------------------------------------------------ Issues with IP Address Sharing, Mat Ford (10 min) ------------------------------------------------------------------------------ http://tools.ietf.org/html/draft-ford-shared-addressing-issues-02 capture issues in all address sharing solutions – collect in one place for reference main changes – several presentations at IETF76, comments on list who the issues impact – deployer only (not a real issue) or third-party need more description on why/how characterized? Right now just a table counting ports should include TIME-WAIT state CPE NAT create issues for TCP control block sharing – this will become more severe Reverse DNS Load balancing – reevaluation of load sharing algorithms State maintenance for mobile host battery consumption – large scale NAT Packet Too Big DoS attack – large scale NAT has to handle Raised awareness at IETF76 – is this appropriate as an Intarea WG work item? Brian Carpenter – very important work. Table – Add a column on whether the issues apply to NAT44 or NAT444. refers to Large Scale – but what are the scaling properties Mat – the analysis could be expanded; Hui – NAT64 address sharing could be across address families Mat – depends on the specific solution Hui – in the translator Mat – workarounds depend on the solution – doc doesn’t get deeply into the specifics of translation solution Hui – encourage discussion Dave Thaler – don’t know if intarea is the right place, maybe behave, but definitely support the work being adopted somewhere, definitely reviewed by both. Alain – NAT flavor doesn’t matter much – conclusions apply to NAT64, NAT44. avoid ping-pong game but someone should adopt this. Rajeev Koodli – valuable to raise awareness. Section 12 onward, TCP etc. concise and ref out or plan to write more? Mat – more of a notated list and references – not a huge doc that tries to cover all the issues in depth. Rajeev – bulleted list of problems would be useful Jari – where to adopt? Here makes sense, could be anywhere, but are we ready to do it? Christian – how many have read? About 20 – please review and comment. On “how baked” it is. Alain – ask whether to adopt. Christian – most of the “readers” are clearly in support of adopting. ------------------------------------------------------------------------------ SmartGrids, Fred Baker (40 min) ------------------------------------------------------------------------------ Slides from EnerNex Corp, SmartGrid in the USA SGIP Smart Grid Interoperability Panel The energy business is more about the flow of money than electricity Networks are never simple, never easy. The Internet can afford mistakes, in the grid, people die. Long lived equipment – 40 year cycles Distributed generation requires phase synchronization – protocol Build up a system that works predictably and scalably Conceptual Model - loose coupling; multilateral development, implementation, operation - layered systems – they mean something else, between different parts of the system (vertical) symmetric peer-to-peer the “grid” includes back end business relationships too the system has to predict demand, too much or too little power are both problems. As load changes, money flows change. Half the electricity in the US is coal fired, oil, natural gas – prices fluctuate. “starting up” a nuke on demand is problematic; some storage is possible Information and electricity both flow through the grid Customer domain – broad spectrum of size, demand, etc. some generation and storage at customer – utility demarcation to control flow of power from customer. Adding smart appliances, home automation, electric vehicles Commercial customers – multiple tenants, larger scale, industrial equipment – lots of complexity. Operational domain – more about moving bags full of money rather than small low power devices. Like the blind men describing the elephant – the smart grid looks very different from the various domains Conceptual Reference Model (see picture) What the IETF/IRTF might find interesting is the “enterprise bus” The impetus for smart grid was a cascading failure, caused by inadequate monitoring and integration of operating equipment. An integrated enterprise bus for the collection of data from all equipment for centralized monitoring and management. Analogous to SNMP…room for research. Example – look at the relatively simple problem of demand response – reducing the demand at peak. Not necessarily binary on/off but variable pricing leading to rational decisions on usage, e.g. backing off thermostat, etc. Very complex – many standards, many connections, many flows. Many SDOs, proprietary developers – leads to fragmented standards, no common e2e Internet Protocol suite is seen as complex – too many options, e.g. what is “the” transport? Vendors see IP as a threat. Kill proprietary approaches, require more space/time Proving that the solutions fit All comm. P2P – must be flexible Current base ANSI C12.19/22 Recommendation – Internet protocol stack with appropriate security AAA, signature and encryption Global perspective – many countries – Japan, Italy, China US perspective – billions on the table, vendors excited Encouraging IPv6 See the slides – plenty more information in the backup slides Jari – “selling IP to the smart grid” do you need a marketing effort? Fred – most things are in the right place. Not a cookbook to describe “how-to” deploy an appropriate network – profiling. Calendaring and timing very relevant. Other applications Jeff Thompson – 40 year time scale? Need to fight that mentality Doug Otis – nukes can’t throttle, in their interest to throttle the load. SCADA interfaces are stupid, errors can be disaster. Our protocols are not adequate to the task – error detection, framing, etc. resynching from odd states. ------------------------------------------------------------------------------ DHCP-based subscriber authentication, Ted Lemon (30 min) ------------------------------------------------------------------------------ http://tools.ietf.org/html/draft-jjmb-dhc-eap-auth-analysis-02 Jari – going on for a long time – 2007 Broad Band forum liaison letters on authentication. Decided to ship off to DHCP WG to analyze. Taken a long time as well. Issues and solutions going around. Time to make a decision, maybe too late, but should we adopt this work in the IETF DHCP extension based on EAP? There are other solutions, PANA, 802.1x, not in a position to dictate to BB forum Ted Lemon “pony in there somewhere” Analysis draft does not represent the WG, Ted and JJ Brozowski individual Not advocating for/against this protrocol PPPoE replacement by DHCP If the relay agent – proxy demands EAP, client provides credentials This is quite complicated very large packets – normally DHCP limited to 576; EAP requires more. Solution: RFC 3396 What if non-conforming clients? The spec should cover this State machine issues – cramming EAP into the DHCP state machine; need to cache state while EAP goes on. Opposing states, lack of synch Is it a relay or a proxy? Defined in spec as a proxy but it sounds like a relay agent; proxy maintains EAP state. Choosing DHCP server based on results of authentication. Dual stack – may authenticate twice, and may be out of synch Analysis has evolved – no clarity about why people are objecting to things until recent discussion – problems arise from mashing the state machines together. No reason to do this – eliminates some major problems. Remove EAP from DHCP state – client should be always receptive to EAP. RFC5505 – requires separating authentication and configuration, but this is not, and allows elimination of PPPoE Spec is weak – inadequate to implement. And as written is harmful. Could be fixed No consensus yet in DHC WG whether to do this Objections to this presentation from both sides of the controversy Punting back to intarea ? decouple state machine – both require lower layers to maintain some state. Ted – EAP state can push information to DHCP – like DHCP lease query scenario, caching state about which server. It would work, if state is lost it repeats the process. ? lower layer still needs to maintain state, in this case DHCP Ted – but no state machine, in broadband environment something caches state of which circuit you are on. This is analogous Dave Thaler – RFC5505 – the doc doesn’t say anything about this particular protocol. By itself it doesn’t solve the problem. It doesn’t require separation, but it is best done separately. ? does not get rid of PPPoe but reinvents it under a new name. Ted – obviously Eric Nordmark – if we can separate the state machines, the problems go away – with dual stack too? Ted – yes, information about the packet can tell the EAP agent the circuit ID or IP address. Prevents dual authentication Eric – timeouts? Ted – windows 95 1 sec lockup. The client needs to keep retrying. These are broken implementations Jari – as an individual. Agree on the state machine separation issue, but there are other issues that require touching the DSLAMs. While we’ve taken too long on this, other things have progressed that help. 1x. doesn’t care about IPv etc David Hankins – large packets – requires everyone to change – non-solution. Ted – nothing says how big a relay agent has to accept. We don’t know – it’s not specified. RFC 3396 – only addresses half the issue. Jari – cut off the mic; David – good summary ? do we have a service provider specification? Do we need a draft? Ted – BBF gave us some requirements, not specified Wojech Dec – useful to examine the requirements ? DSLAM drops the packet; option 82 – in analysis draft; key corner cases missing; looking for a solution that covers all use cases. If possible we need one solution – and start from scratch. Requirements doc – willing to help Jari – poll should this work go forward? Who believes this work should go forward? 4-5. not? 5-6. not consensus – going to the list, make a decision and move on.