ROLL Working Group Meeting - IETF-77 - March 2010 - Anaheim - USA Thanks to Bob Power for taking the minutes. 1) WG Status (Chairs - 10 mn) [15] Excellent progress We're about 1 IETF meeting behind. Need to freeze the specs. A new Security Design Team was formed Security framework document: see to quickly adopt it as a WG document All Requirement documents are now done (the last two ones (building and home automation) in RFC editor queue Good use of tickets assigned to quickly track and solve specific issues. 2) IPR at the IETF (Adrian Farrel - 10mn) [25] if you are an author or an editor BCP 78 BCP 79 - RFC 3979; RFC 4879 If you know about IPR that may covers or may ultimately cover, you need to declare it. http://www.ietf.org/ipr/file-disclosure Patent Trolls 3) RPL: Routing Protocol for Low power and Lossy networks (Phil/Pascal ? - 40 mn) [65] draft-ietf-roll-rpl-07 New version draft-ietf-roll-rpl-07 DIO stable Room for simplification s-bit t-bit prefix in DIO's consistency (what/when) Room for refinement role of OF movement DAO - when to push a DAO when to push a DAO Review of open tickets ---------------------- #17 - LSRR updates - recommend we close this #21 - flow label - - comment: carpenter draft; label will be changed within the network by the routers; IPV6 says label will be delivered unchanged #23 - OCP Object - should rpl or metrics draft specify the OCP object? #24 - P2P Performance - how do we make RPL specific P2P scenario One option is to use "reactive DIS" message across the dodag -ttl = 5 -forward limited # of DIS copies -not ready to conclude on this Comment: push model & pull model Comment: 2 issues - a. broken round - need to get a packet fast; b. how do we setup routes in normal case (dao) Comment: maybe we should split this into 2 problems Comment: prefer to keep it as a single ticket start the applicability statement at the same time Question: given the nature of Low Power Lossy Networks some cases we have mission critical data; other times we can wait are we trying to provide a comprehensive solution for everything? Answer: we are trying to solve everything in our requirements documents JP suggests to start working on the Building/Home applicability statement, determine potential gaps so as to augment the RPL spec with needed additional mechanisms. #25 - RPL Satisfying the MUST requirements ; JP will send a list of MUST from the requirements IDs to track them to make sure that RPL meets these requirements. If not, WG decision. If I read RFC 2190 correctly; you MUST implement the MUST or you break interop #26 - Mixed operation - should rpl specify modes to store and another to not store If a storing node fills its routing table, what happens? Clarification: there really is no mixed operation Clarification: proposal is to have all stored or all non stored Comment (PT): not happy with what we have Comment: benefit of mixed mode operation Show of hands - strongly in favor of no mixed mode #27 - DAO ack - should we protect the DAO with an ack? Comment: may want an API hook that allows either in case mac has an ack #28 - Source Route Failure Clarification - what do you mean by failure? Answer - there are mechanisms that determine next hop is not reachable Other room for refininement --------------------------- Miscellaneous / editorial ------------------------- Reporting to the root (eg request global repair) Options in DIS (security, filters) Still some inconsistencies -DAG vs DODAG 4) Routing Metrics used for Path Calculation in Low Power and Lossy Networks (Kris Ð 5 min) [70] draft-ietf-roll-routing-metrics-06 JP> Two tickets resolved related to metric format. No major change. 5) A Security Framework for Routing over Low Power and Lossy Networks (Tzeta Ð 10 mn) [80] draft-tsao-roll-security-framework-02 Requirements --integrity --authentication --guard against message replay --encryption may be desirable Threat Analysis for RPL --application of security policy --attacker capability --trust Attack Surface Design Guidelines --equip rpl with selectable methods Question: don't you want to consider end to end security Answer: yes, but will start with a baseline 6) Update from the RPL Security DT (Kris Pister for the Security DT Team - 20mn) [100] Routing security Later or out of scope --policy --key distribution --insider attack Summmary - can provide simple, standard, lightweight, mechanisms - min 2b per data packet - type 5b per dis/dio/dao - lots of work to do Discussion - errors & alarms are an open issue - useful to have nodes in the field detect/react to - link layer security is preferrable -- true, but some things will not have link layer security - what is CCM*? -- should include a reference to it so it can be analyzed - would want to see more on why you chose crypto you did, specifically on key sizes agree, we will have justification on this - Robby Simpson, GE - is it an assumption that ROLL will do its own security? -or rely on l2 or l3 -goal is to turn it off if you have security you need 7) The ETX Objective Function for RPL draft-gnawali-roll-etxof-00 (Omprakash Gnawali - 5mn) [105] ETX Metric Some considerations - frequency of updates; hysterisis to prevent churn ; path / link thresholds Question: how much state is needed for ETX metric? state is proportional to number of neighbors 8) The Trickle Algorithm - draft-levis-roll-trickle-00 (Thomas/Phil - 5mn) [110] Trickle - proposal is to make trickle separate ---------------------------------------------- - anyone opposed to making it a separate document? --no one objected 9) Update from IPSO on RPL Interoperability testing (Mathilde Durvy for IPSO - 10 mn) [120] IPSO Interop ------------ Mar 24/25 - RPL testing Goal - core functionality - dynamic formation of DODAG - OF0 OF - global repair - local repair - hop by hop routing - support of trickle