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

On Sun, Apr 14, 2013 at 3:53 PM, Hendrik Brummermann <nhb_web@nexgo.de> wrote:
> Am 13.04.2013 22:24, schrieb Yuchung Cheng:
>> On Sat, Apr 13, 2013 at 5:52 AM, Hendrik Brummermann <nhb_web@nexgo.de>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.
Great point. Will incorporate that in the security section of next
revision. Thanks.

>
>
>>> 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.
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm