I've run into a problem whose root cause is that a particular network
device (an Alteon load balancer) doesn't retransmit SYN-ACKs that are
lost--instead, it will only send another SYN-ACK if the client retransmits
the SYN packet. This is a problem because a PIX firewall that's sitting
in front of the Alteon is dropping duplicate SYNs from the client if it
sees the SYN-ACK from the Alteon...so if the SYN-ACK makes it to the
PIX but is then lost somewhere on the Internet, the connection is never
established (because the Alteon never sees another SYN and so it never
sends another SYN-ACK).

My question is: is this RFC-compliant behavior? Based on RFC 793 (section
1.5) it would seem that after sending the SYN-ACK, the receiver should
retransmit that packet after the timeout expires without the receiver
having gotten an ACK--regardless of whether or not it's gotten another
SYN from the sender. But maybe I'm reading the RFC incorrectly, or maybe
this requirement doesn't kick in until after the initial 3-way handshake,
or maybe a later RFC (2581?) modifies this requirement in regard to the
3-way handshake.

I've observed the same behavior on Linux, BTW--it only sends another
SYN-ACK to a client if the client has sent another SYN. So apparently
this is a common way to handle the 3-way handshake.

- John

John Caruso wrote:

> I've run into a problem whose root cause is that a particular network
> device (an Alteon load balancer) doesn't retransmit SYN-ACKs that are
> lost--instead, it will only send another SYN-ACK if the client retransmits
> the SYN packet. This is a problem because a PIX firewall that's sitting
> in front of the Alteon is dropping duplicate SYNs from the client if it
> sees the SYN-ACK from the Alteon...so if the SYN-ACK makes it to the
> PIX but is then lost somewhere on the Internet, the connection is never
> established (because the Alteon never sees another SYN and so it never
> sends another SYN-ACK).

It's a basic rule of Internet security that you never transmit more
data to a source than you think you got from it until you can be sure
the claimed source is the real source. Otherwise, you can be used for
amplification attacks.

Sadly, each device's behavior seems fairly reasonable in isolation.

DS

On 2006-11-15, John Caruso <johnSPAMcarAWAYuso@myprivacy.ca> wrote:
> I've observed the same behavior on Linux, BTW--it only sends another
> SYN-ACK to a client if the client has sent another SYN.

Fairly major correction: based on further testing it appears that Linux
only behaves this way if it receives an ICMP unreachable in response to
the sending of the initial SYN-ACK (as outlined in section 4.2.3.9 of
RFC 1122); otherwise, it does in fact retransmit the SYN-ACK packets,
just as RFC 793 would suggest should be done.

By contrast, the Alteon *never* retransmits a SYN-ACK. So I'm back to
thinking that the Alteon is violating the RFCs with this behavior.

- John

On 2006-11-15, David Schwartz <davids@webmaster.com> wrote:
>> I've run into a problem whose root cause is that a particular network
>> device (an Alteon load balancer) doesn't retransmit SYN-ACKs that are
>> lost--instead, it will only send another SYN-ACK if the client retransmits
>> the SYN packet. [...]
>
> It's a basic rule of Internet security that you never transmit more
> data to a source than you think you got from it until you can be sure
> the claimed source is the real source. Otherwise, you can be used for
> amplification attacks.
>
> Sadly, each device's behavior seems fairly reasonable in isolation.

You could argue that, but my question wasn't whether or not the behavior
was reasonable but rather whether or not it violates the RFCs. I'm pretty
sure it does, but it would be ful (in my discussions with Nortel/Alteon
in particular...) to have that verified--and even better to know the specific
section of the specific RFC that it's violating. As I said, I think it's a
violation of section 1.5 of RFC 793, but I haven't read through other TCP-
related RFCs closely enough to know if they contradict that (or if they
ouline retransmission behavior during the 3-way handshake more thoroughly).

- John

John Caruso wrote:

> By contrast, the Alteon *never* retransmits a SYN-ACK. So I'm back to
> thinking that the Alteon is violating the RFCs with this behavior.

Even if they are, they have an ironclad justification. It is an error
to send more data back then you get in if you cannot confirm the
source. This is essential to stop amplification attacks.

When you receive a SYN, you have no way to verify the source. So
responding with three times as much data as you got would be bad. That
would allow an attacker who can spoof X megabits to hit a victim with
3X megabits. (Even if you rate limit, an attacker could make a list of
amplifiers and use each one just a little bit.)

DS

On 2006-11-16, David Schwartz <davids@webmaster.com> wrote:
> John Caruso wrote:
>> By contrast, the Alteon *never* retransmits a SYN-ACK. So I'm back to
>> thinking that the Alteon is violating the RFCs with this behavior.
>
> Even if they are, they have an ironclad justification. It is an error
> to send more data back then you get in if you cannot confirm the
> source. This is essential to stop amplification attacks.

I understand that that's your opinion, though I'd say you're overstating
it quite a bit and I also disagree with you--as do the RFCs (apparently),
and the TCP maintainers for Solaris, OpenBSD, Linux, and Windows Server,
since I've verified that all of those retransmit unacknowledged SYN-ACKs.

But that's beside the point. Again: I'm asking if anyone knows (or rather
can verify) if this behavior violates the RFCs, and if so it'd be nice to
know which section of which RFC deals with this the most explicitly.

- John

In article <slrnelo7cc.3oo.johnSPAMcarAWAYuso@news.sbcglobal. net>,
John Caruso <johnSPAMcarAWAYuso@myprivacy.ca> wrote:

>>> By contrast, the Alteon *never* retransmits a SYN-ACK. So I'm back to
>>> thinking that the Alteon is violating the RFCs with this behavior.
>>
>> Even if they are, they have an ironclad justification. It is an error
>> to send more data back then you get in if you cannot confirm the
>> source. This is essential to stop amplification attacks.
>
>I understand that that's your opinion, though I'd say you're overstating
>it quite a bit and I also disagree with you--as do the RFCs (apparently),
>and the TCP maintainers for Solaris, OpenBSD, Linux, and Windows Server,
>since I've verified that all of those retransmit unacknowledged SYN-ACKs.

Saying that the other person's view is quite a bit overstated is itself
understated. 3 or 4 retransmissions of SYN-ACKs is not enough amplification
to care about, unless there is something else in the path like a router
that does directed broadcasting, and then the directed broadcasting
would be the problem. As far as I can tell, other people don't worry
about amplifications of 10X or more (e.g. SPF-DNS).


>But that's beside the point. Again: I'm asking if anyone knows (or rather
>can verify) if this behavior violates the RFCs, and if so it'd be nice to
>know which section of which RFC deals with this the most explicitly.

Because RFCs are not laws, that does not sound like an effective tactic
for convincing your vendor to change its product. Whether the product
does not retransmit SYN-ACKs on bogus "amplification attack" grounds,
some sort of SYN-bomb defense, or some other reason, waving RFC text
is unlikely to convince them to change. If your business is not valuable
enough to them to convince them, you'll probably have to take it
elsehwere. That they have apparently not had you talking to the technical
people responsible for the product is a pretty bad sign that they don't
care much about losing your business.


Vernon Schryver vjs@rhyolite.com

On 2006-11-16, Vernon Schryver <vjs@calcite.rhyolite.com> wrote:
>>> Even if they are, they have an ironclad justification. It is an error
>>> to send more data back then you get in if you cannot confirm the
>>> source. This is essential to stop amplification attacks.
>>
>>I understand that that's your opinion, though I'd say you're overstating
>>it quite a bit and I also disagree with you--as do the RFCs (apparently),
>>and the TCP maintainers for Solaris, OpenBSD, Linux, and Windows Server,
>>since I've verified that all of those retransmit unacknowledged SYN-ACKs.
>
> Saying that the other person's view is quite a bit overstated is itself
> understated.

Yes, that was intentional--I just wanted to make this digression end and
get back to the point.

>>But that's beside the point. Again: I'm asking if anyone knows (or rather
>>can verify) if this behavior violates the RFCs, and if so it'd be nice to
>>know which section of which RFC deals with this the most explicitly.
>
> Because RFCs are not laws, that does not sound like an effective tactic
> for convincing your vendor to change its product.

True, but also a digression. I'm just asking a straightforward question
about the TCP RFCs, and still hoping that someone who's more familiar with
them than I am can provide an answer.

On that digression: yeah, of course citing RFC chapter and verse isn't
likely to change their minds (in isolation), and yeah, any vendor dopey
enough to break TCP at such a fundamental level in their hardware isn't
worth further business anyway (and believe me, this is just one of many
major/glaring bugs in the old Alteon product line). But the device in
question is a load balancer, and so the effect of this bug is to break
every single content-based load balancing method--because to do any
content-based load balancing the device must handle the 3-way TCP handshake
itself, and with the lack of SYN-ACK retransmissions you consistently get
connection timeouts if SYN-ACK packets are lost somewhere after they leave
the box. So this isn't just a minor violation of some obscure section of
some musty RFC somewhere...it's fundamental to how they do load balancing.

- John