Fernando Gont wrote:
At 23:42 15/02/2005 -0800, Joe Touch wrote:
>>> Validating ICMP messages, using information already available (e.g.
>>> sequence numbers), in the same way that TCP itself validates
>>> segments, seems entirely a good thing, and architecturally sensible.
>>> Are there actual arguments against it?
>> The window isn't restricted from wrapping in the time an ICMP might be
>> generated, is it?
> Maybe theoretically true, but the Maximum Segment Lifetime effectively
> limits most ICMP generation.
Sure (we're still talking about non-malicious routers for this case).
However, that's not to say it won't shift sufficiently that the sent
ICMP will be outside the receive window (it may not wrap, but it may
shift enough that you can't use the 'window' to check it).
And what's the problem with this? ICMP is not reliable, after all.
If the ICMP source is sufficiently out of sync, it will always generate
ICMPs that end up outside the window. Not reliable != never works.
>> If you get something wrong, do you NACK it and try to get the other
>> end to send the right seq number,
> "To avoid the infinite regress of messages about messages etc., no ICMP
> messages are sent about ICMP messages." -- RFC 792
Agreed. So what happens when a legitimate ICMP is received that you now
reject? How do you restore current functionality?
For most cases I can think of, some other ICMP error message will be
elicited by some other TCP segment.
In any case, as stated above, ICMP error messages are not reliable.
As above, if you always generate ICMPs outside the window (by the time
they're received), then NONE of them get through...
tcpm mailing list