Re: [tcpm] WG Last Call for ICMP Attacks

[Joe Touch <touch at ISI.EDU>]

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



Carlos Pignataro wrote:
> Please find a couple of comments inline.
> 
> On 9/9/2009 2:07 AM, Joe Touch wrote:
>>
>> Fernando Gont wrote:
>>> Hello, Joe,
>>> Thanks for your feedback! Comments in-line....
>>>> - --
>>>> 2.1 indicates reasons why ICMPs are not reliable; it should include
>>>> reasons why ICMPs could be late - so late that, e.g., sequence numbers
>>>> aren't relevant.
>>>> - --
>>> Could you clarify what you have in mind, specificaly? ICMP error
>>> messages being assigned lower priority than normal traffic, or what?
>>> FWIW, routers typically rate-limit ICMP errors...
>> Routers aren't required to emit ICMP errors on any particular timescale.
>> They can queue the events and get around to them - whenever.
> 
> IMHO, this comment might need some realistic qualification -- "whenever"
> seems overly excessive and too dramatic in real life. Routers do not try
> to do busywork and delay ICMP generation (exaggeration purposely
> intended to counter-balance).

"whenever" is when routers get to do it. Consider a router that has an
error in its queue to process. A user installs an upgrade and reboots
it, during which it is offline. Or it goes down and comes back for power
reasons. In either case, there is *no* requirement that such errors be
flushed.

Routers sometimes get locked up doing various things. Their control
planes often operate completely independently of the data plane, and
have priorities that can starve various routines that aren't required to
be timely. Errors that get hit with that could end up on the wire
seconds, minutes - *any* time later.

And they'd be *compliant* with FC1812.

>> That
>> includes queues, low priority processing, etc. Regardless of rate
>> limiting, there's still no requirement about timeliness at all.
> 
> Yes, router architectures get more complex, but so do solutions. In many
> architectures, for example, ICMPs are generated by the line-card CPU,
> avoiding any central RP delay, and RP<->LC path. The more busy the
> router could get, the more switching is done in hardware, and the more
> free cycles control-plane CPUs get. My 2¢.
> 
> If it feels like déjà vu, this topic was discussed at:
> <http://www.ietf.org/mail-archive/web/tcpm/current/msg03623.html>
> Joe Touch > Routers are not required to return ICMPs on any particular
> Joe Touch > timescale.
> thread started at:
> <http://www.ietf.org/mail-archive/web/tcpm/current/msg03621.html>

I raised it several times before. Bob Braden reiterated it in the
microphone line at an IETF a while ago too. It never made it into this
doc, however, and it should.

Joe

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

iEYEARECAAYFAkqnuTAACgkQE5f5cImnZrsY6QCfUEBATafVEX80QuC1qpS7r34s
h10Anjni76IiXXNzQaFfLTh+G5F4LQFt
=4My3
-----END PGP SIGNATURE-----