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

---

From: [email-masked]
Date: Fri, 30 Aug 2002 13:50:54 -0400

On Fri, 30 Aug 2002 02:05:58 PDT, coursemate groupsix <[email-masked]>  said:

> 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:

Adobe was seriously embarassed in the Skylarov incident when it turned out
their encryption was of this form.  It's not even *close* to sufficient in
today's Internet.  For that matter, even single-DES is considered not sufficient.

First off, substitution ciphers are prone to frequency-analysis attacks, and
other tricks - if you're trying to encrypt "Packet Too Big", and there's only
a limited number of other possible values, you can just compute what the
key value would have to be for each possible text to result in the given
ciphertext, and see if it works for the rest of the message.  I expect this
would be computationally on the same order as the TCP checksum - in other
words, microseconds.

Second off, how do you distribute your "key value of 10"?  If everybody uses
10, it's not a key anymore....

I suggest you get a copy of Bruce Schneier's "Applied Cryptography", read it,
understand it, and then think about why this is a *lot* harder than it looks
(hint - how do you get the key to secure a Neighbor Discovery packet if you
haven't gotten enough neighbor/router information to find your DNS server
or other network information packet?).

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "David J. Aronson" <[email-masked]>
Date: Fri, 30 Aug 2002 13:58:37 -0500

[email-masked] wrote:

> substitution ciphers are prone to frequency-analysis attacks,

This reminds me of something I recently wondered about, and now decided
to inflict on y'all.  I've dealt with crypto just enough to be dangerous
to my OWN self; I'm no expert, so please bear with me.

How do cryptanalysis programs know when they've got it right?  I am told
(by my dad, who did it in WWII, but hasn't kept up on the technology)
that the main way, barring having a specific string to match or other
distinguishing characteristic, is frequency analysis.  That is, when
it's wrong, the letter (or rather, character) frequency distribution is
rather flat, but when it's right, it's spiky, in a manner that resembles
most human languages.  (For instance, English has spikes at the classic
ETAOINSHRDLU spots, and lows at the "Scrabble letter" spots, though of
course these will generally be located differently if a simple
substitution cypher is used.)  Are there other ways commonly used?  For
now, I will proceed along the assumption (yes, I know what happens
then!) that this is still the main way.

Now, suppose you salt the plaintext with rarer characters, so as to
flatten out the distribution.  That is, first you analyze the frequency
distribution of the plaintext, then compose a string of some given
length, that will have enough of the rarest characters to make the
frequency graph fairly flat, and then intermix them in some prescribed
manner.  This could even be done in such a manner that any reasonably
long subset of the altered (but not yet "encrypted") plaintext would
have a fairly flat frequency graph, as opposed to, say, using up the
rarest characters first.

How would cryptanalysis programs deal with that?  Do they usually apply
a "desalination" step to see if it can sensibly make a subset with a
spiky distribution?  If so, how would it tell the actual message, from
any other spiky subset?  (After all, even totally random garbage would
contain a multitude of spiky subsets!)  Or is there some other reason
why the idea of adding such salt simply wouldn't help make encryption
more secure?

-- 
David J. Aronson, Software Engineer for hire in Philadelphia area
Resume, and other details, online at: http://dja2001.home.att.net
Looking for work[ers] in Philly?  See the Yahoo group PhillyJobs.

---

From: John Stracke <[email-masked]>
Date: Fri, 30 Aug 2002 15:39:20 -0400

David J. Aronson wrote:

>flatten out the distribution.
>  
>
I believe compression has the same effect, actually--compression uses 
fewer bits for common characters, and the result is that the 
distribution of bytes is flatter, and harder to attack.

-- 
/=====================================================\
|John Stracke      [email-masked]            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"No, no, that's *not* a boat, that's Queen Victoria."|
\=====================================================/

---

From: [email-masked]
Date: Fri, 30 Aug 2002 16:14:55 -0400

> How do cryptanalysis programs know when they've got it right?  I am told

It has to do with what's called the "unicity distance" - if we're expecting
to decrypt and find English, what are the chances that a random key will produce
1, 2, 3 blocks of English?

http://www.counterpane.com/crypto-gram-9812.html has a writeup on it.

---

From: "David J. Aronson" <[email-masked]>
Date: Sat, 31 Aug 2002 10:28:44 -0500

> distribution of bytes is flatter, and harder to attack.

Come to think of it, that's even better than the salting I was
proposing, as it (usually) isn't restricted to printable chars.  So,
let's go with that approach.  Say you take the plaintext, zip it, then
encrypt it.  The question remains, given that the frequency distribution
is fairly even, how does a cryptanalysis program know when it's got it
right?  (If "they" know you've used a specific publicly available
compression program, they can look for its "signature" at the start, but
let's ignore that for now....)

---

From: "Perry E. Metzger" <[email-masked]>
Date: 31 Aug 2002 18:58:41 -0400

I would suggest that a cryptography mailing list or newsgroup is a
better place for this discussion -- it is not of IETF-wide
interest. None the less...

"David J. Aronson" <[email-masked]> writes:
> How do cryptanalysis programs know when they've got it right?

That's what the unicity distance metric is about -- it lets you judge
the probability that you have the right key. I'd suggest reading
Shannon on this. The whole reason you can't break a one time pad is
that the unicity distance is infinite -- you can't tell that you have
the right key even if you guessed it perfectly.

> flatten out the distribution.

Techniques like this were first brought to bear hundreds of years ago.
I'd suggest a read of "The Codebreakers" by Kahn if you are interested
in the topic.  Such mechanisms (including padding with nulls,
homophonic substitutions, etc.) are long since superseded but at the
time provided additional security to the ciphers and codes of the day
-- they are now primarily of interest to historians of the field,
although that is not to say that nothing like them is ever discussed
any longer.  See, for example, Rivest's Chaffing proposal of some
years ago.

-- 
Perry E. Metzger		[email-masked]
--
"Ask not what your country can force other people to do for you..."