IPv6 Implications on the Management Plane. Huawei, Shenzhen,

Transcription

1 IPv6 Implications on the Management Plane Jürgen Schönwälder Huawei, Shenzhen, / 30

2 Introduction 1 Introduction 2 Plain IPv6 Management is Simple? 3 Scenario: IPv4-to-IPv6 Transition Mechanisms 4 Scenario: Machine-to-Machine in Constrained Networks 5 Conclusions 2 / 30

3 Simplicity vs. Complexity RFC 1925 It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. RFC 3439 Simplicity Principle: complexity must be controlled if one hopes to efficiently scale a complex object. John C. Doyle The evolution of protocols can lead to a robustness / complexity / fragility spiral where complexity added for robustness also adds new fragilities, which in turn leads to new and thus spiraling complexities. 3 / 30

4 Some general remarks about network management... Observations The less (explicit) management is needed, the more cost effective it is to run a network. Generally, the simpler the network structure is, the less (explicit) management is needed. When rolling out new technologies, think early about the information and tools needed to debug problems. Robust automation to support workflows reduces (explicit) management and increases consistency and efficiency. Challenge When evolving the network, think whether it is possible to simplify the network at the same time new features are rolled out try to establish incentives for customers to help you in simplifying the netwok. 4 / 30

5 Plain IPv6 Management is Simple? 1 Introduction 2 Plain IPv6 Management is Simple? 3 Scenario: IPv4-to-IPv6 Transition Mechanisms 4 Scenario: Machine-to-Machine in Constrained Networks 5 Conclusions 5 / 30

6 Cost of running IPv4 and IPv6... Assumption Running a plain IPv6 network is not more complicated or costly than running an IPv4 network. C(IPv4) C(IPv6) When is the assumption justified? If the IPv6 support in devices is as robust and efficient as the IPv4 support. If the IPv6 management and debugging tools are as good and robust as the IPv4 management and debugging tools. If the automation-level is the same for both IPv4 networks and IPv6 networks. If the humans involved understand IPv6 as good as they understand IPv4. 6 / 30

7 Cost of running IPv4 and IPv6... What about running both IPv4 and IPv6? But, running an IPv4 and an IPv6 network concurrently is more expensive than just running an IPv4 network: Influencing C(IPv4 + IPv6) C(IPv4) + C(IPv6) C(IPv4 + IPv6) = C(IPv4) + C(IPv4 + IPv6) C(IPv4) C(IPv6) Consistency ( simplicity) in both the IPv4 and IPv6 world. Additional automation to help maintain consistency. Ultimately, C(IPv4 + IPv6) must be a transient state. Control the time spent in the state C(IPv4 + IPv6). 7 / 30

8 Scenario: IPv4-to-IPv6 Transition Mechanisms 1 Introduction 2 Plain IPv6 Management is Simple? 3 Scenario: IPv4-to-IPv6 Transition Mechanisms 4 Scenario: Machine-to-Machine in Constrained Networks 5 Conclusions 8 / 30

9 Simplicity vs. Complexity Evolution of access networks RTR NAT B4 global prefix global address NAT B4 GW NAT NAT global address Internet 9 / 30

10 Management Implications Examples... NAT traversal issues application protocols got extended discovery protocols (STUN) got invented MTU discovery issues NATs tweaking MSS in TCP SYN exchanges? really? New possible attacks (e.g., address pool exhaustion) some form of throttling mechanism needed more management and monitoring needed Irritations for diagnostic tools (e.g., traceroute) sudden interactions with firewalls additional header options may be needed (all depending on tunnel technologies used) 10 / 30

11 Proactive IPv6 Transition Failure Detection Just an outline of a still rough idea... Smart management software might be able to detect application failures caused by IPv6 transition mechanisms. Once detected, take an active approach to inform the user/customer and provide hints how to transition best (e.g., which software to upgrade). Must be an optional service to turn on/off (do not annoy a customer if he has good reasons to live with the problem) Might be scalable to implement if transition related application protocol failures leave sharp signatures in aggregated flow records 11 / 30

12 Scenario: Machine-to-Machine in Constrained Networks 1 Introduction 2 Plain IPv6 Management is Simple? 3 Scenario: IPv4-to-IPv6 Transition Mechanisms 4 Scenario: Machine-to-Machine in Constrained Networks 5 Conclusions 12 / 30

13 Managing the Internet of Things AVR Raven Hardware ATmega1284PV microcontroller: runs at 20 MHz 16K of RAM 128K of ROM (Flash) Contiki-SNMP Contiki is an operating system for embedded devices SNMP engine (written in C) for constrained devices built on top of the Contiki uipv6 stack (6LoWPAN) 13 / 30

14 IPv6 over Low-Power Wireless Personal Area Networks IEEE Small frame size (max frame size = 127 bytes) Low power devices (some battery operated) Limited memory and processing power Low bandwidth (max data rate = 250 kbps) Large scale and dense deployments Devices and channels tend to be unreliable Devices may use sleep schedules to conserve energy IETF 6LoWPAN IPv6 over IEEE (see RFC 4944) General motivation and overview (see RFC 4919) RPL (routing), COAP (web transfer protocol), / 30

15 Management of 6LoWPAN Networks Typical management questions How many nodes disappeared during the last night/day? How many nodes joined during the last week? What is the temperature, pressure, energy usage (add your favorite sensor here) distribution within the network? What is wrong with my home automation network? How does the routing topology look like? How does the routing topology change if I change the location of nodes? / 30

16 SNMP and 6LoWPAN: End-to-End SNMPv3 end-to-end SNMP Manager SNMPv3 SNMP Agent Internet 6LowPAN Network + Straightforward direct access to individual 6LoWPAN nodes + Reuse of existing deployed SNMP-based tools o End-to-end security, end-to-end key management - Message size and potential fragmentation issues - 6LoWPAN nodes must run an SNMP engine - Trap-directed polling nature of SNMP has high (energy) costs 16 / 30

17 SNMP and 6LoWPAN: Proxies SNMPv3 proxies SNMP Manager SNMPv3 SNMP Proxy (6LowPAN Gateway) SNMPv3 SNMP Agent Internet 6LowPAN Network + Indirect access to individual 6LoWPAN nodes + Alternate transport encoding can reduce message sizes o Reuse of existing SNMP-based tools supporting proxies o Two security domains, different key management schemes - 6LoWPAN nodes must run an SNMP engine - Trap-directed polling nature of SNMP has high (energy) costs 17 / 30

18 SNMP and 6LoWPAN: Subagents SNMPv3 subagents SNMP Manager SNMPv3 SNMP Agent (6LowPAN Gateway) Subagent Protocol SNMP Subagent Internet 6LowPan Network + Indirect access to individual 6LoWPAN nodes + Alternate transport encoding can reduce message sizes o Reuse of existing SNMP-based tools supporting contexts o Two security domains, different key management schemes o 6LoWPAN nodes must run an SNMP subagent - Trap-directed polling nature of SNMP has high (energy) costs 18 / 30

19 SNMP and 6LoWPAN: Data Fusion Protocols SNMPv3 interfacing to data fusion protocols SNMP Manager SNMPv3 SNMP Agent (6LowPAN Gateway) data fusion protocol WSN Peer Internet 6LowPan Network + Indirect access to individual 6LoWPAN nodes + Leveraging data fusion protocols (in-network aggregation) + SNMP agent acting as a cache, no expensive polling o Reuse of existing SNMP-based tools supporting contexts o Two security domains, different key management schemes? No direct advantage of 6LoWPAN technology oops 19 / 30

20 Contiki-SNMP Overview General features / limitations SNMP messages up to 484-byte length Get, GetNext and Set operations SNMPv1 and SNMPv3 message processing models USM security model, no VACM access control model API to define and implement managed objects USM security algorithms HMAC-MD5-96 authentication protocol (RFC 3414) CFB128-AES-128 symmetric encryption protocol (RFC 3826) 20 / 30

21 Implemented MIB Modules and Static Memory Usage MIB modules SNMPv2-MIB SNMP entity information IF-MIB network interface information (no iftype) ENTITY-SENSOR-MIB temperature sensor readings SNMPv1 and SNMPv3 enabled bytes of ROM (around 24% of the available ROM) 235 bytes of statically allocated RAM SNMPv1 enabled 8860 bytes of ROM (around 7% of the available ROM) 43 bytes of statically allocated RAM 21 / 30

22 Flash ROM and Static Memory Usage Memory usage by software module (bytes) Module Flash ROM RAM (static) snmpd.c dispatch.c msg-proc-v1.c msg-proc-v3.c cmd-responder.c mib.c ber.c usm.c aes cfb.c md5.c utils.c / 30

23 Stack and Heap Usage Maximum observed stack usage Version Security mode Max. stack size SNMPv1 688 bytes SNMPv3 noauthnopriv 708 bytes SNMPv3 authnopriv 1140 bytes SNMPv3 authpriv 1144 bytes Heap usage not more than 910 bytes for storing an SNMPv1 message approximately 16 bytes for every managed object in the MIB if a managed object is of a string-based type, then additional heap memory is used to store its value 23 / 30

24 SNMP Request/Response Latency (varying security) Time (ms) SNMPv1 SNMPv3 noauthnopriv SNMPv3 AuthNoPriv transfer processing SNMPv3 AuthPriv 24 / 30

25 SNMPv1 Request/Response Latency (varying # varbinds) request-response delay round-trip time processing time 120 Time (ms) Number of variable bindings in a request 25 / 30

26 Bigger Picture (resource requirements of various protocols) &'3%)*%+,-% 3'(%)*%+0-% D5E8% /'2%)*%+,-% 3'&%)*%+0-% 8E-"%.% E9>:FGH% J'3%)*%+,-% 3'7%)*%+0-% KAA"%.% IF0"% 6%)*%+,-%.%&'7%)*%+0-% L% 45"% &'6%)*%+,-%.%3'7%)*%+0-%!"#$% &&'(%)*%+,-%.%&'/%)*%+0-% AI"% J%)*%+,-%.%3'7%)*%+0-% +"1% 2'(%)*%+,-%.% 3'3&%)*%+0-% 26 / 30

27 Directly Related Work at Jacobs University SNMP applicability to constrained devices Guidelines how to fit SNMP into constrained devices Tricks like making VACM a simple read-only/read-write switch <draft-hamid-6lowpan-snmp-optimizations-02.txt> RPL MIB module specification and implementation Definition of a MIB module for the RPL routing protocol Implementation and evaluation on Econotags <draft-sehgal-roll-rpl-mib-01.txt> DTLS for constrained devices Contiki-SNMP over DTLS (RFC 5590, RFC 5591, RFC 5953) 27 / 30

28 Other Related Work at Jacobs University NETCONF Lite implementation and specification Profile (subset) of NETCONF 1.1 (RFC 6241) Single session, hence trivial locking No <edit-config>, no <get> / <get-config> filtering No optional capabilities No security (yet)... First prototype shown at the Prague IETF (on AVR Ravens) <draft-schoenw-netconf-light-00.txt> Multicast DNS for network management service discovery Managers use mdns to discover manageable devices Devices discover management services via mdns Contiki-mDNS implementation already running <draft-schoenw-opsawg-nm-srv-02.txt> 28 / 30

29 Conclusions 1 Introduction 2 Plain IPv6 Management is Simple? 3 Scenario: IPv4-to-IPv6 Transition Mechanisms 4 Scenario: Machine-to-Machine in Constrained Networks 5 Conclusions 29 / 30

30 Conclusions Operational considerations Operational IP network management costs can be controlled Key is controlling complexity Long-term evolution towards simpler networks needed (this may require to set the right incentives) IPv4-to-IPv6 transition should be transient not permanent Vendor considerations Management support can be a distinguishing factor Transition technologies will lead to new failures modes and hence require additional network management support Constrained M2M networks do require management but it is not clear yet how to do this best 30 / 30