Subject: Comment (RFC 2463)

From: coursemate groupsix <[email-masked]>
Date: Fri, 30 Aug 2002 02:05:58 -0700 (PDT)

Dear All,

Below is the comment and suggestion for RFC 2463 (Internet Control Message Protocol for IPv6)...

Hope there is a response and feedback to this RFC...

Thank You.

Comment and Suggestion for Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) –RFC (2463)

       The purpose of these control message (ICMP) is to provide feedback about problems in the communication environment and it is not to make IP reliable. Thus, there are still no guarantees that a datagram will be delivered to its destination and also there are no guarantees that a control message will be returned to its source. Some datagrams may still be undelivered without any report of their loss. This is due to the fact that; in this paper the packet will be dropped and the ICMPv6 message would not be generated if a packet involve in the congestion. In this case maybe the higher level protocols that use IP for example the transport layer if TCP is used or the application layer if UDP is used, must implement their own reliability procedures if reliable communication is required. Beside that, the bandwidth utilization will be increased because some of the packet would not arrived to its destination and will be discarded if an ICMPv6 informational message of unknown typ!
 e is received, the router receives a packet with a Hop Limit of zero or a router decrements a packet’s Hop Limit to zero and if an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension header such that it cannot complete processing the packet.

       Even though in some cases it will give an impact to the bandwidth utilization where it can maximize the used of the bandwidth, but in certain cases as provided in this paper, the bandwidth utilization can be limited. For example, sometimes when  a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error message. So, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error message, an IPv6 node must limit the rate of ICMPv6 error message it sends. Variety of ways introduced in this paper for implementing the rate-limiting function such as:

i) Time-based function

   In  this technique maybe the rate of transmission an error message to a given source or to any source are limited to at most once every T millisecond for example.

ii) Bandwidth-based function

   In this technique the rate at which error message are sent from a particular interface to some fraction F of the attached link’s bandwidth are limited to a certain value.

       Based on the RFC (2463), although the ICMP messages is needed to provide feedback about problems in the communication environment, but it still being exposed to the ICMP attack. One of the attack is that the ICMP message may be subject to changes in the message fields or payload. In order to prevent this type of attack, I suggest that the message fields should be encrypted from the sender and decrypted by the receiver. One heuristic strategy that we can use is substitution. The process of substitution involve each cleartext being replaced with some other character. The result of this substitution will be a ciphertext that does not resemble the original text in any obvious manner. One famous example is the Caesar substitution which work as follows:

1. Let say the message is:

              Packet Too Big

2. ASCII numeric representation is used for each character.

      P    a    c      k     e     t     spaces      T      o       o     spaces       B    i     g

   80   97   99  107  101 116     32        84     111   111    32          66  105 103

3. Adding suitable integer (known as key value) to each of the ASCII value above. Let

    say the key value is 10.

    90     107     109      117    111     126     42     94    121     121    42     76    115    113

     Z       k         m         u        o          ~       *       ^       y          y      *       L        s       q

4. Thus, the error message “Packet Too Big” would be encrypted under key 10 as:

              Zkmuo~*^yy*Lsq

5. The process of substitution can be done repeatedly (more complex scheme) so as to

     ensure that decryption is difficult without knowledge of the key value.

---------------------------------
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes