Re: [tcpm] WG Last Call for ICMP Attacks

[Joe Touch <touch at ISI.EDU>]

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



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. That
includes queues, low priority processing, etc. Regardless of rate
limiting, there's still no requirement about timeliness at all.

>> 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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqnRjkACgkQE5f5cImnZrsmZACg7OrUOrfV8HMx7jmXSndfolRO
0iQAoNnVicCl6ZMdLw5wj+PunXcY6zzz
=EjYy
-----END PGP SIGNATURE-----