III. WSNs NETWORK LAYER ISSUES:

The network layer provide user specific upper layers with independence from the data transmission and switching technologies used to connect network nodes/systems; responsible for routing i.e., network layer determines which physical path the data takes, based on the network conditions, the energy efficiency of route, reliablility of relaying of data from the sensor nodes to sink, priority of service and other factors as well as resolving the logical node address with the physical address if necessary.

Routing is a very challenging task in WSNs due to several characteristics that distinguish them from other communication networks and wireless Ad-hoc networks. Performance of routing protocol closely related to architechtural model.

Also at this layer we identified these Denial of Service (DoS) attacks and we need these types of DoS defense mechanism to tackle these DoS Attacks:

Table 1: DoS Attacks and Defenses

DoS Attacks	DoS Defenses
Neglect and Greed	Redundancy, Probing
Homing	Encryption
Misdirection	Egress filtering, Authorization, Monitoring
Black Holes	Authorization, Monitoring, Redundancy

IV. IPv6 INSTEAD TO IPv4 FOR WSN:

IPv6 is better suited to wireless sensor networks than IPv4 whereas it has larger headers and defines more functionality. The large address space not only supports a huge number of devices, but it also eliminates many of the artificial naming constraints of IPv4. As a result, an adaptation layer in RFC 4944 (6LoWPAN) was defined that carried the meaning of IPv6 addresses in a very compact form using small IEEE 802.15.4 addresses. Additionally, the various Layer 2 bootstrapping and discovery mechanisms were consolidated in ICMPv6, bringing them into the same IPv6 architecture. Lastly, IPv6 defines link-local communication to enable simple, single-hop networks.

V. SECURITY MECHANISM WITH IPv6:

The Internet protocol is a connectionless protocol. It treats each message independently, forwarding it through the network to its final destination. By convention, the packets that IP transfers are called datagrams. Each IP datagrams begins with a common header as shown in fig.-2.

With IP version 6, TCP/IP offers several important security features. All IP version 6 hosts are required to support authentication. In addition, IP has a well-defined framework for exchanging confidential messages. Both features were initially designed just for IP version 6. As a testament to their power and usefulness, though, both have adapted for use with IPv4 as well.

5.1. Extension Headers:

IPv6 is much more flexible in its support of options. Options appear in extension headers that follow the IP header in the datagram.

5.2. Built-in Security:

IPv6 requires support for both authentication and confidentiality.

Extension headers (as shown in fig.-3) follow the basic header in the IP datagram. The IP standard defines several different extension headers; each one is identified by a particular value for the next header field as shown below:

Value	Description
0	Hop-by-Hop Options Header
43	Routing Header
44	Fragment Header
51	Authentication Header
59	No Next Header
60	Destination Options Header

Every extension header (except 59) has its own next header field. The final extension header uses its next header field to identify the upper-level protocol. The order of extension header is important because it makes it easy for intermediate routers to process the datagram efficiently. Fig.-3 shows the headers in the recommended order.

For security purpose Authentication header ensures that a received datagram is authentic-that it was not already in transit and that it truly come from the claimed sender. Authentication is part of the enhanced security features of IP version 6.

5.3. Security Association:

Both authentication and confidentiality rely on security associations. A security association establishes the context for the communication, and it usually defines several security aspects of that communication important characteristic of a security association, are described as follows:

· Specific encryption or authentication algorithm is use.

· Time limits on the keys or the entire association.

· Sensitivity of the protected data (e.g. secret, top secret and so on).

· Other parameters of the algorithm (e.g. synchronization data or initialization vectors).

· Specific key or keys to the communication.

5.4. Authentication:

All IPv6 further specifies the Message Digest 5 (MD5) algorithm as the default authentication algorithm, and all hosts must support this algorithm, if both parties agree, they may optionally use a different authentication algorithm, otherwise they are free to omit it from their datagrams.

The authentication information itself begins with the security parameters index, or SPI. When combined with the destination address, the SPI defines the security association for the communication. Actual authentication data follows the SPI. It must consist of an integer number of 32-bit words. The security association determines which authentication algorithm is in use. If the default MD5 algorithm is employed, then the authentication data consist of 16 bytes. To compute the authentication data using MD5, the sender starts with a secret authentication key. If that key is shorter than 128 bits, enough zero bits are added to make it 128 bits long. Immediately after these 128 bits, the sender appends the complete IP datagram itself. That datagram should have an authentication header in place, but the authentication data within that headers is set to zero, in addition, all fields in the datagram that can change in transit (the hop limit field, for example) are temporarily set equal to zero. After the datagram, the sender adds the authentication key once more. It is this block of data that the sender passes through the MD5 algorithm; the algorithm generates a 128-bit digest, which is used as the authentication data within the authentication header.

The receiver performs the same steps. It starts with the padded authentication key, adds the datagram (temporarily zeroing the authentication data and other fields that may have changed in transit), and appends the key once more; the MD5 digest for this should match the authentication data. If it does not, the datagram is not authentic, and the receiver takes appropriate steps.

The whole process works because only the sender and the receiver know the secret authentication key, since no other system knows this key, no other system can generate a datagram that will have the correct digest when the receiver checks it.

5.5. Confidentiality:

Authentication is important for the security of IP datagrams, but it does not guard against the most basic security threat eavesdropping. As IP datagrams traverse a network, they may travel through many different systems and networks. These intermediate links offer opportunities for someone other than at the destination to examine datagrams and discover their contents.

Protecting against this treat requires confidentiality, and IP provides that with its encapsulating security payload (ESP). ESP is the standard way to send encrypted information within IP datagrams.

All systems that support ESP must support the default an encryption algorithm. That algorithm is the cipher blocking chaining (CBC) mode of the data encryption standard (DES). The algorithm itself, specified by the US government, is beyond the scope of this text. The format of the ESP with this algorithm, however, is straightforward.

VI. VARIOUS SENSOR NODES PLATFORM CONFIGURATIONS - A REVIEW:

Wireless sensors or Motes are sensing modules. Sensors usually compose of four basic units: a processing unit with limited computational power and limited memory, a sensing unit/sensors (including specific conditioning circuitry), a communication unit (transceiver), and a power unit (battery).

Resource footprint [12, 13, 14] for various currently available Sensors/Motes provides us a summary that most of the Sensors/Motes belongs to within the following configuration:

· 4-bit to 8-bit processor

· 512 Byte to 512 KB RAM (Program and Data Memory)

· 4 KB to 4 MB Flash/External Memory

· 250 Kbps 2.4 GHz IEEE 802.15.4 or Bluetooth 2.0 or 10 Kbps etc. as radio transceiver

On the basis of above mentioned resource footprint we reach on a conclusion that each and every currently available sensor nodes face limited resource problems such as narrow address space and slow clock cycle of micro controller, small program and data memory as well as external memory, low bandwidth and low range of transceivers.

Since resource conservation is a key consideration in low-power wireless sensor applications. The resources that matter to achieving deployment ubiquity, long-lived power autonomy, and cost effective devices include: low protocol overhead in bandwidth on the radio, low program memory requirements, low data memory requirements, and low power usage through intermittent and often infrequent operation.

VII. uIPv6:

uIPv6 is the world's smallest certified open source (licensed under a 3-clause BSD license that allows it to be used in both closed source and open source projects) IPv6 stack provides TCP/IP connectivity to tiny embedded 8-bit micro controllers for low-cost networked device such as sensors and actuators with maintained interoperability and RFC standards compliance.

uIPv6 is not tailored to any particular link layer, but should run on any link layer over which IPv6 is designed i.e. the uIPv6 stack runs over any MAC and link layer, such as 6LowPAN/IEEE 802.15.4, IEEE 802.11 and Ethernet. This is possible because interface between uIPv6 and the lower layer consists of two wrappers for link layer input/output functions: the link layer address and some constants. This creates a level of abstraction, which enables the easy integration of various MAC and link layer protocols.

7.1. Platform requirements for uIPv6:

The uIPv6 code size is approximately 11.5 KB. The RAM usage is distributed as follow: 0.2 KB for general code, 0.3KB for neighbor discovery data structures, 1.3 KB for the main buffer. The total RAM usage is thus around 1.8 KB. If IPv6 fragmentation is supported an additional buffer of 1.3KB is used. If during the address resolution process per neighbor buffering is supported, an additional 1.3 KB of RAM is needed per neighbor.

7.2. Platforms supported by uIPv6:

The uIPv6 stack is implemented in Contiki. Contiki is the memory-efficient open source operating system for networked embedded devices that includes the uIPv6 stack. In addition, Contiki includes an IPv4 stack (the original uIP stack), TCP and UDP support, as well as the Rime radio communication stack. Contiki also provides standard OS features like threads, timers, random number generator, clock, a file system, and a command line shell. Although uIPv6 is included in Contiki, uIPv6 itself does not require an operating system. Embedded device with enough resources may chose to run a real time operating system such as FreeRTOS. uIP IPv4 implementation runs on FreeRTOS, and uIPv6 is easily ported to FreeRTOS. Contiki with uIPv6 runs on the Atmel Raven, Tmote Sky/TelosB, as well as under simulation, and on a number of other AVR-based and MSP430-based platforms.

7.3. Point of failure of uIPv6 in context with Security Issues:

uIPv6 is the answers of interoperability problem but due to the restriction to fit IPv6 packets in 127 bytes 802.15.4 frames the main security features such as authentication and confidentiality are left.

VIII. CONCLUSION:

There is growing interest in exploiting standard Internet protocols such as IPv6 in wireless sensor networks. Support for IPv6 has the potential to facilitate application development, increase the flexibility of sensor node interaction, and better integrate sensor nodes into the ‘Internet of things’. Unfortunately, IPv6 is poorly suited for resource-constrained environments and is particularly wasteful for typical wireless sensor network data flows. From the above described issues related to WSNs network layer, security and other advanced features available with IPv6 and detail survey on sensors/motes we found that for implementing security features during data transmission in form of packets we need to implement IPv6 on WSNs but on memory constrained devices, the limited amount of buffer space makes it impossible to support the reassembly of very large packets. It is also unrealistic to except that a node would be able to buffer one packet per neighbour during the address resolution process. The 6LowPAN-working group reduces the size of IPv6 packets to make them fit in 127 bytes 802.15.4 frames. Now uIPv6 with Contiki resolves our problem for end-to-end interoperability between uIPv6 and Contiki supported sensors and any IPv6 capable device. To allow widespread community adoption, working group [14] release uIPv6 under a permissive open source license that allows both commercial and non-commercial use. We make next generation of WSNs more secure at network layer if we implement uIPv6 for all operating systems for resource-constrained devices. As well as to implement full fledge security features of IPv6 such as authentication and confidentiality we need large memory space on sensors/motes so with the help of micro electronics we need some new high capacity low energy consumed small memory chips that should be fit for next generation WSN requirements.

REFERENCES:

1. A.K. Dwivedi, M.K. Tiwari, O.P. Vyas, “Operating System for Tiny Networked Sensors : A Survey”, International Journal of Recent Trends in Engineering (Computer Science), [Page 152-157] Vol. 1, No. 2, ISSN 1797-9617.

2. Carlos de Morais Cordeiro, Dharma Prakash Agrawal “Ad Hoc and Sensor Networks”, World Scientific Publication 2006, ISBN 981-256-681-3, ISBN 981-256-682-1.

3. S.K. Basandra and S. Jaiswal - “Local Area Networks”, Galgotia Publications, 2001, India. [Pages 416.80-416.90].

4. “RFC Index retrieved from” - http://www.rfc-editor.org/rfc-index2.html

5. RFC 4862: IPv6 Stateless Address Autoconfiguration [S. Thomson, T. Narten, T. Jinmei] [Ed.-September 2007].

6. RFC 2373, 3513, 4291 - IP Version 6 Addressing Architecture [R. Hinden, S. Deering] [Ed.-Jul 1998, Apr 2003, Feb 2006, respectively].

7. Rodriguez, Adolfo; John Gatrell; John Karas; Roland Peschke (2001-08-06). "Internet transition - Migrating from IPv4 to IPv6". TCP/IP Tutorial and Technical Overview. IBM.

8. The IPv6 Forum. http://www.ipv6forum.com/.

9. The IPv6 Ready Logo Program. http://www.ipv6ready.org.

10. RFC 4443: ICMPv6 for the IPv6 Specification [A. Conta, S. Deering, M. Gupta] [Ed.-Mar 2006].

11. RFC 4944: Transmission of IPv6 packets over IEEE 802.15.4 Networks [G. Montenegro, N. Kushalnagar, J. Hui, D. Culler] [Ed.-Sep 2007]

12. “WSNs Mote hardware survey retrieved from” - http://www.cse.unsw.edu.au/~sensar/hardware/hardware_survey.html

13. “Another WSNs Mote hardware survey retrieved from” - http://senses.cs.ucdavis.edu/resources.html

14. “Another WSNs Mote hardware survey retrieved from” - http://www.snm.ethz.ch/Main/Homepage

15. Mohit Saxena, Purdue University, West Lafayette – “Security in Wireless Sensor Networks A Layer-based Classification” [CERIAS Tech Report 2007-04].

16. Mathilde Durvy, Julien Abeillé, Patrick Wetterwald, Colin O’Flynn, Blake Leverett, Eric Gnoske, Michael Vidales, Geoff Mulligan, Nicolas Tsiftes, Niclas Finne, and Adam Dunkels belongs to Swedish Institute of Computer Science, Cisco Systems, NewAE, Atmel Corporation and Proto6 LLC – “Poster Abstract: Making Sensor Networks IPv6 Ready” [Sensys’ 08, Nov 2008, USA] [ACM 978-1-59593-990-6/08/11].

17. RFC 4120: The Kerberos Network Authentication Service (V5) [C. Neuman, T. Yu, S. Hartman, K. Raeburn] [Ed.-Jul 2005].

18. RFC 4537: Kerberos Cryptosystem Negotiation Extention [L. Zhu, P. Leach, K. Jaganathan] [Ed.-Jun 2006].

19. RFC 5021: Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP [S. Josefsson] [Ed.-Aug. 2007]

20. Adum Dunkels, Fredik Osterlind, “Contiki Programming Course: Hands on Session Notes”, SICS- October 2008.

21. Adam Dunkels, Bjorn Gronvall, and Thiemo Voigt, “Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors”, In Proc. of First IEEE Workshop on Embedded Networked Sensors, November 2004.

Received on 27.07.2009

Accepted on 30.07.2009

Research J. Science and Tech. 1(1): July-Aug. 2009: 16-19