>>What do you think Ipsec does with an RST frame with an incorrect
>>IP-AH MD5 signature ? Exactly the same thing.
>IPsec is fundamentally different because it encapsulates all IP
>traffic, not just TCP. The packet is killed at IP if it doesn't
>pass the signature.
You are certainly correct that the IP layer is a better place to implement
authentication checksums.
>>I'm not saying the RFC is a good idea (tho its a needed patch to
>>use Linux for backbone routing sanely with most vendors BGP
>>kit). Your argument about the RST frame is however pure horseshit
>I totally disagree.
>Look, TCP is the last place more complexity needs to exist.
>Errors in logic in TCP need to be dealt with by breaking the
>connection and spitting a RST out, and it must be done in a
>way that is as easy to verify as possible.
I don't follow the logic of this argument. When you receive the initial SYN,
you'll either be able to confirm its checksum or not. Once you can confirm
the checksum, you know that the key is the same on both ends, so there's no
fear that a valid subsequent RST will be rejected.
There is an issue at the connection establishment phase. If you receive a
packet with a bad checksum, what do you do? There is some complexity here,
but the obvious solutions work. If one end can correctly sign a packet, you
know they will correctly accept a packet. Until you have received a packet
whose checksum you have validated, you accept unvalidatable packets.
>IPSEC getting the signature wrong is more akin to getting bitstream
>corruptions from your networking card for a certain sequence of bytes.
It really comes down to the question of what is or isn't a valid RST and
whether TCP option specifications have the 'right' to override other
provisions of the TCP specification.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/