Re: [tcpm] WG Last Call for ICMP Attacks

[Carlos Pignataro <[e-mail]>]

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

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

Thanks,

-- Carlos.

> 
>>> In Sec 4.1:
>>>    It should be note that as there are no timeliness for ICMP error
>>>    messages, the TCP Sequence Number check described in this section
>>>    might cause legitimate ICMP error messages to be discarded
>>>
>>> This should also note that it is also possible to end up acting on ICMPs
>>> that are old even when such checks are in place, depending on the
>>> lateness of the ICMP and the width of the valid sequence number window.
>> I have no problem with this. However, the doc tries to address
>> deliberate attacks rather than ligitimate old packets. That said, if you
>> still feel this should be addressed in the document, please let me know
>> and I will incorporate text about this.
> 
> The point is that the solutions tries to deal with deliberate attacks,
> but *in doing so* it changes how it reacts to legitimate events -
> whether legitimate old packets (above) or other legitimate events that
> would otherwise have been ignored (due to state). It's important to note
> this change.
> 
> Joe
> 
>>> - --
>>> top Page 13, space is missing:
>>>    synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
>>>    CLOSING, LAST-ACK or TIME-WAIT)as "soft errors".  That is, they do
>> Thanks!
> 
> 
>>                                   ^
>>> - --
>>> Section 8 would benefit from a summary of the different techniques used
>>> (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs,
>>> etc.) and a description of how each basic technique affects the system -
>>> i.e., they (in general) make the system more robust to deliberate
>>> attacks, but could make the system react less rapidly to legitimate
>>> network errors. This is a deliberate trade-off, and perhaps a reasonable
>>> one, but worth noting, IMO.
>> Will do.
> 
>> Thanks again!
> 
>> Kind regards,
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm