Re: [tcpm] WG Last Call for ICMP Attacks

Joe,

Thanks for the response, please see inline.

On 9/9/2009 10:18 AM, Joe Touch wrote:
> 
> 
> 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.

My point was not about impossibility, but about qualifying these
possibilities with a of tint of (and gauge them with their degree of)
operational realism. Have you (personally or second hand) seen an ICMP
being delayed by minutes?

> 
> And they'd be *compliant* with FC1812.

I think that it should refer to what the specs envision, and not
necessarily to an ICMP delayed several minutes during an upgrade: e.g.,
rate-limit as per <http://tools.ietf.org/html/rfc1812#section-4.3.2.8>;
note that for example the specs even deal with ICMP generation for
bursts of traffic (e.g., traceroute), at
<http://tools.ietf.org/html/rfc4443#section-2.4> item (f).

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

The document says the following; would s/discarded/discarded or delayed/
cover it?

   It is important to note that ICMP error messages are unreliable, and
   may be discarded due to data corruption, network congestion or rate-
   limiting.  Thus, while they provide useful information, upper layer
   protocols cannot depend on ICMP for correct operation.

Thanks,

-- Carlos.

> 
> Joe
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm