mailing list archives
Re: nping echo protocol rfc, feedback
From: "Luis MartinGarcia." <luis.mgarc () gmail com>
Date: Sun, 20 Mar 2011 20:26:39 +0100
Again, sorry for the late reply. I've reconsidered some of your
On 03/11/2011 03:59 PM, Toni Ruottu wrote:
There could be multiple simultaneous connections in which case the
"the previous NEP_HANDSHAKE_CLIENT message" might have arrived over
another connection. Changing this to "the preceding
NEP_HANDSHAKE_CLIENT message" would clarify the situation, if I
understood the meaning correctly.
Ok, the text now reads "the preceding" message.
In the same chapter the explanation of Error Message field explains
requirements for null characters. I think it would make sense to
clarify that the last byte of the field needs to be null in all cases.
I don't agree with this one. I thinks that can be trivially inferred
from the description.
It can be inferred, but it is also a fact that always holds. And
stating facts that always hold is useful. Any other part of the
explanation only affects the end result, while having the last byte
always be null, is a safety measure. Of course an implementation
should not rely on the last byte being null.
I am worried that someone might store an error message which is
exactly 640bits, thinking that the terminator is not required when the
whole field is used. Alternatively you could clarify the maximum
length of the message. "The null terminator always takes one byte,
leaving 632bits for the string payload."
I still think that there is no way to interpret the text wrong. It says:
Contains a NULL-terminated ASCII string that describes the reason
why the session is being terminated by the sender. The string MUST
contain a NULL character (0x00) at the end of it. The remaining
bytes, if any, must also be set to zero.
It states twice that the string has a NULL byte at the end, and there
is a big MUST there so I'm sorry but I prefer no to change the current
In the key explanations sometimes the concatenation is marked as
(SERVER_NONCE|CLIENT_NONCE) and sometimes not. I tried really hard to
figure out if the two cases were different, but I am still not sure. I
think they are the same. Maybe the notation should be copied to all
cases or dropped.
You are right. I've replaced the "|" symbol with the plus sign to make
all concatenations consistent.
That was not the problem. I'll clarify
For NEP_KEY_MAC_C2S it is said that "NONCES equals the server nonce in
the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce
in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE)"
For NEP_KEY_CIPHERTEXT_C2S it is said that "NONCES equals the server
nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the
client nonce in the NEP_HANDSHAKE_CLIENT message."
Why is the later one lacking the equation? Some of the descriptions
have the equation and some do not have it. Is there a difference?
Should all of them have the equation?
At first I did not understand what you were trying to say but now I do
so I've added the equation to the description of all keys.
I've just updated the RFC. Thanks again for taking the time to review
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/