Re: [tcpm] WG Last Call for ICMP Attacks

[Joe Touch <[e-mail]>]

-----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-----