At 21:36 27/09/2006, Carlos Pignataro wrote:
> It is not yet clear to me why you need to include in the ICMP error
> message more data than the first chuck from the original datagram.
> What type of problem does these extensions let me solve?
>
> This type of stuff should be present in the introduction (if not in
> the abstract itself).
These seem to be covered in the Introduction:
Protocol
designers can make an ICMP message carry additional information by
encoding that information in an extension.
...
Reference [6] and reference [7] provide
sample applications of the ICMP Extension Object.
I think the text I just received from Ron addresses my point. I
basically asked to state clearly what is the motivator of these
extensions. i.e. "we are trying to solve X problem, we cannot do this
with the current ICMP messages because Y (blah, blah)"
> I'm don't really know if there are any implementations that perform
> the TCP checksum. Firstly, because the driver of all the ICMP
> modifications proposed in the ICMP attacks draft is security, and the
> checksum doesn't improve it. Secondly, because in many (most?) cases
> you won;t receive a full datagram to be able to check it.
>
> But what's in that draft is pretty much what most vendors have
> implemented. That's why I think a clarification on this aspect
would be useful.
The evaluation of these scenarios seems to be inline with what the draft
currently says:
So, only those ICMP applications that
process the 129th octet of the "original datagram" field will be
adversely effected. To date, no such applications have been
identified.
I get a feeling from this paragraph that "there's no problem, because
nobody is doing this". I'd switch the discussion to "what if somebody
were doing this?". There's the case of the checksum, but there's also
the case of rewriting other fields, such as the port numbers.
As I have stated in other posts, you may certainly get to the
conclusion that in most deployed scenarios, there won't be much
trouble. The reasons being:
* You are just playing with ICMP "soft errors". Therefore, even if an
error message is misdirected, there won;t be a connection reset, or anything.
* In most cases, it will be impossible to check the TCP checksum.
(Probably the only possible case is that of ICMP error messages
elicited by pure ACK segments)
* Use of IP options: I bet the header does not usually get to 60
(although I would have to look back at the IPsec spec)
And there might be others...
Kindest regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
