Re: [tcpm] WG Last Call for ICMP Attacks

["Anantha Ramaiah (ananth)" <ananth at cisco.com>]

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.

Joe has brought this up multiple # of times and I don't really see this
as an issue. The merits of this seq# check far outweigh the de-merits,
if any. If you have extendeded ICMP support then we could check more to
get even more robustness. (example if timestmaps are available one could
make use of it) We have been using the seq# check in our boxes for quite
some time (Fernando's draft mentions many other popular OS'es using this
method) So, far they have been no issues in the field. 

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. 

Just my few bits...

-Anantha

> -----Original Message-----
> From: tcpm-bounces at ietf.org [mailto:tcpm-bounces at ietf.org] On 
> Behalf Of Joe Touch
> Sent: Wednesday, September 09, 2009 8:21 AM
> To: Carlos Pignataro (cpignata)
> Cc: Smith, Donald; 'tcpm Extensions WG'; 'David Borman'; Fernando Gont
> Subject: Re: [tcpm] WG Last Call for ICMP Attacks
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Carlos Pignataro wrote:
> ...
> >> It's OK to qualify it with "this is unlikely", but IMO it 
> needs to be 
> >> discussed with more than a single word in a single paragraph.
> > 
> > I think that "this is unlikely" or "this is highly unlikely" would 
> > still be understating the probability (I am curious to see any 
> > experienced example of ICMP being delayed minutes). Redundancy 
> > architectures of routers typically cover the planned 
> upgrade (or even 
> > unexpected reload) scenarios you presented.
> > 
> > Perhaps a separate sentence in that paragraph before the 
> "Thus, " with 
> > some variation of "rate-limiting can delay ICMPs, and some other 
> > highly unlikely theoretical scenarios can compound the delay"?
> 
> You can't rely on something that isn't required. The fact 
> that current implementations, in current operation, don't do 
> this isn't relevant.
> 
> Consider the proposal to resend 'the last packets seen' after 
> a link outage, to 'tickle' TCP into waking up. That proposal 
> was considered inappropriate because the router would hold 
> the packet too long to satisfy requirements. However, if 
> someone were to propose to hold ICMPs and issue them later, 
> that would be *compliant*.
> 
> Protocols aren't just about what happens to work today; 
> they're about what you can expect to work tomorrow too. 
> Anything that examines the contents of an ICMP needs to 
> appreciate that those contents do NOT have to obey timeliness 
> requirements - notably of the protocol being conveyed as 
> payload. You need to explain what happens when your 
> assumptions are wrong not because they're often wrong today, 
> but because you cannot know whether they'll be wrong tomorrow.
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkqnx90ACgkQE5f5cImnZrvguwCgrm7/fLMiKak8gGb0QYQsROeK
> 5bcAn0fxfPIznaScGG9Tx0oq0OjCHk8x
> =xegI
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>