Re: [tcpm] WG Last Call for ICMP Attacks

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Anantha,

Anantha Ramaiah (ananth) wrote:
> Jumping in to this thread since I had mentioned it many times earlier
> that delayed ICMP's causing issues for seq # check is impractical today.
> On the client side validation we can have the following scenarios :-
> 
> #1 - ICMP comes in and doesn't match the current segments (or in some
> implementations packets) sitting in the retransmission queue, thus the
> ICMP is silently dropped. No harm.
> #2 - ICMP arrives and it matches the sequence #, this is the usual case.
> No harm if false positives are handled correctly.
> 
> 
> The cause for concern is the case where the ICMP packet gets delayed for
> a long time and the sequence number has wrapped around and the seq # no.
> exactly falls in the window of packets sitting in the retransmit queue.
> This cam happen only when the data is sent at a very fast rate and such
> cases extra checks are necessary. OTOH, if the ICMP packet seq#  falls
> outiside (> SNDNXT) in such cases this is for something not yet sent,
> discard it. No harm
> 
> IMO, this is not an issue at all, these false positives can be handled
> with appropriate checks in the code.

Please just put this in the doc. This issue comes up. It may not affect
this solution, but it is important to include it - to say that it isn't
an impact. I have asked for similar language in the long-delays doc, but
I'm not sure what the impact there is.

...
> My proposal would be to add some text to what Joe is concerned about,
> highlight the fact that it is mostly theoritical and hence should not be
> a concern. If needed some quantification can be done, but I really don't
> see the point. 

No quantification. A version of what's above is what I'm seeking, though
if we're considering everything we never see in the wild theoretical, we
can gut a lot of complexity out of TCP. IMO, this isn't theoretical -
it's *compliant*, and you can make the case that you do no harm when it
happens. That's the point, and that's what needs to be in the doc, IMO.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqn0fcACgkQE5f5cImnZruF0QCg8YKWBuLtDuwNTiTxYjRtgK0X
KJQAoJV+FzgzeQ7ZwxfaoBgkkET7TIBh
=pyWu
-----END PGP SIGNATURE-----