RE: [tcpm] feedcback on tcp-secure-05

<snip>

> >> > would be. Without such blocking, it's not clear what the 
> utility of 
> >> > this solution would be.
> >>
> >> Ok.
> > 
> > I don't think tcpsecure should make any advice on what to 
> do with ICMP.
> > 
> > Just make it clear that the introduced mechanisms do not prevent 
> > ICMP-based attacks against TCP, and provide a pointer to 
> > draft-ietf-tcpm-icmp-attacks-00.txt .
> > 
> > If you are going to make any other statement on this issue, 
> state that 
> > the ICMP-based attacks are easier to perform, and thus should be 
> > mitigated (if not, it's ICMP that is the "weakest link in 
> the chain").
> > 
> > You could also add that, fortunately, virtually every 
> implementation 
> > has mitigated the ICMP attacks described in 
> > draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most 
> (if not all) 
> > the counter-measures described in that draft.
> 
> That last point doesn't obviate the issue that ICMP packets - 
> even validated by the mitigations in the draft above - are 
> still easier to spoof and can be spoofed by third parties 
> than any of the attacks in tcp-secure.
> 
> I.e., they remain the weakest link, and worrying about 
> tcp-secure protections is nonsensical by comparison, UNLESS 
> ICMPs are entirely blocked.

Actually I have to dis-agree to this. The tcp-secure is by no means an
exhaustive list of attacks that can be performed on TCP layer. It's main
focus is on providing robustness to some of the blind in-window attacks.

Now we have a separate document which talks about the ICMP based attacks
(draft-ietf-tcpm-icmp-attacks-xx.txt) and it's mitigation, so it would
be better to just provide a reference to the same in tcp-secure and
leave it at that. To make recommendations on to blocking ICMP is outside
the scope of tcp-secure.

Another point to note is that TCP SHOULD act (not a MUST) on ICMP
reported hard errors. Also in some cases like "port unreachable" can be
ignored since TCP uses the RST for the purpose of port unreachability.
This is as per RFC 1122. 

- Some applications would chose to ignore the so called hard errors for
a TCP connection. In other words the behaviour can be controlled by a
CLI and the default would be to ignore this hard errors. So the
connection reset wouldn't happen.

- Some firewalls deliberately block ICMP messages rendering the attack
useless.

I guess my point is ICMP attacks may be a weakest link, but wouldn't
cause connection resets with proper installed workarounds in place. Yes,
I mean without voilating the current RFC's.

Also with or without ICMP mitigations in place, one could still cause a
TCP connection to RESET, if the mitigations described in tcp-secure
isn't present. So the tcp-secure suggestions are useful with or without
ICMP blocking/unblocking. But is it foolproof ? It isn't. Using MD5
makes the connection reset even harder, other tougher MAC's even harder.
So all I am trying to derive is that, I agree with Fernando about
tcp-secure shouldn't be making any recommendations on whether to block
or unblock ICMP messages. I think these drafts are orthogonal to each
other.

But it would be ok to mention about the ICMP attacks in the security
considerations of tcp-secure and provide a pointer to the same.

-Anantha
> 
> Joe
> 
> 
> 

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm