Subject: [tcpm] TCP Fast Open and dynamic IP-address assignments

From: Hendrik Brummermann <[email-masked]>
Date: Sat, 13 Apr 2013 14:52:38 +0200

The section on security consideration mentions carrier grade NAT as a
potential issue. A similar issues exists in the context of dynamic
IP-address assignments:

An adversary may request a TFO cookie and disconnect from the Internet.
A new user will get the same IP-address. But the adversary can still
send packets with the TFO cookie, spoofing this ip-address as source.

In addition to the reflection of large answer packets to the current
user, this makes it likely that the current user is blamed for malicious
actions caused by the adversary. Log files on the server will show the
IP-address and the current timestamp.

While the NAT gateway may prevent TCP Fast Open by filtering the flags,
there seems to be no way an Internet user can protect himself against
the previous user of his ip-address.

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 13 Apr 2013 13:24:03 -0700

> send packets with the TFO cookie, spoofing this ip-address as source.
Are you suggesting the current text
http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03#section-6
is not clear on this case? happy to revise if it's not clear.

> IP-address and the current timestamp.
so is a regular SYN flood. btw the "large answer" packets are limited to
the initial TCP congestion window

> the previous user of his ip-address.
yes if the ISP allows any user to send IP packet with (previously owned)
spoofed IP packet.
(and so is regular syn flood).

_______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Hendrik Brummermann <[email-masked]>
Date: Mon, 15 Apr 2013 00:53:10 +0200

> is not clear on this case? happy to revise if it's not clear.

I am sorry, I missed the last paragraph of the introduction section.

PPP/PPPoE is used by most boardband providers at least in Germany
instead of DHCP. Large ISP here force an IP-change on end-users every 24
hours.

> the initial TCP congestion window

In case of a syn flood it is widely assumed that the source address is
forged. But in case of webserver logs, it is reasonable likely that the
source address and timestamp will lead to the real origin of the
connection. It may either be the attacker themselves or a relay which
might be used with or without permission. (Yes, a TCP three way
handshake can be faked in some circumstances, but this is reasonable
unlikely).

It may be a good idea to document the risks of TFO in the context of
blaming innocent clients more clearly. It basically means that each log
entry timestamp gets blurred into a timeframe which goes back into the
past for the validation duration of the TFO cookie.

> yes if the ISP allows any user to send IP packet with (previously owned)

The packets may be sent using another ISP.

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 16 Apr 2013 11:20:51 -0700

> past for the validation duration of the TFO cookie.
Great point. Will incorporate that in the security section of next
revision. Thanks.