|
|
Fernando Gont wrote:
At 07:45 16/02/2005 -0800, Joe Touch wrote:
>> > You assume that TCP window will move, when it won't.
>>
>> Why not? what if packets find another path?
>
>
> If packets find another path and there's progress on the conenction, it
> means that the connectivity problem being reported by those ICMP error
> messages is not true anymore... so why would you abort the
corresponding
> connection, lower the PMTU, or whatever?
>
> It would be extremely nonsensical to do so.
You wouldn't. How would you know not to, either way?
ugh?
Your argument was that the TCP SEQ could mean that we could drop
"legitimate" packets. Either the packets are not legitimate, or they
report an error condition that is not true anymore.
So why should we honor them?
There are other cases where you might do somthing different or not - but
that'd be your choice, not forced by who sends you most recent TCP
headers.
Note sure what you mean.
I still don't understand your argument against the TCP SEQ check.
I have responded to every argument you raised, but it seems there's
always "something else".
You haven't considered all the cases, which is where I started - that
mods to TCP are problematic this way.
That of "not honoring old ICMP messages" has been responded, and I think
it's clear enough that not only there's no harm in performing the TPC
SEQ check, but that you *should* do it.
Not only could the ICMP messages be generated by attackers, but also as
a result of old incarnations of the same connection.
And nothing in ICMP is designed to address the age of the connection in
regards to the ICMP signal.
Having hosts use IPsec just because of this is, IMO, a bad idea. An
*expensive* sequence number, for which you should keep state at IP (!).
It's fun that we have been discussing since about April 2004 about how
to solve an attack which assumes the four-tuple is known, and the
attacker must guess the TCP SEQ, but there's is discussion on performing
the same TCP SEQ checking on received ICMP packets.
With similar problems. Except that the other attack is a TCP attack;
this is an ICMP attack. Performing the same check is not indicated.
Everyone that has read the draft has seen the stuff as something that
should have been there since a long time ago. That includes vednors,
open source folks, and even old timers.
Not everyone. Some of us see it as yet another attempt to secure the net
inappropriately.
Joe
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|