Re: [tcpm] WG Last Call for ICMP Attacks

[Fernando Gont <[e-mail]>]

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



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



> - --
> 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,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1