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

[Hendrik Brummermann <[e-mail]>]

Am 13.04.2013 22:24, schrieb Yuchung Cheng:
> On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann <[e-mail]>wrote:
>> 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.
> 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.

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.


>> 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.
> so is a regular SYN flood. btw the "large answer" packets are limited to
> 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.


>> 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.
> yes if the ISP allows any user to send IP packet with (previously owned)
> spoofed IP packet.

The packets may be sent using another ISP.