Subject: Re: [tcpm] ICMP attacks draft (issue 1): hard errors -> soft errors (in synchronized states)

From: Joe Touch <[email-masked]>
Date: Fri, 30 Sep 2005 21:33:46 -0700

Lloyd Wood wrote:
> On Fri, 30 Sep 2005, Joe Touch wrote: 
> 
>>Fernando Gont wrote:
>>
>>>At 03:36 p.m. 30/09/2005, Joe Touch wrote:
>>
>>...
>>
>>>>>"The strength of  a chain is that of the weakest link", I mean.
>>>>
>>>>But TCP-antispoof explains that the chain is already sufficiently weak
>>>>in many cases even if you try to fix ICMP.
>>>
>>>It's weak. But we are making it weaker unnecessarily.
>>
>>What's weaker than weak enough? (and why would we need to modify a core
>>Internet protocol if it's still weak enough)?
> 
> Using bad rhetoric and word games against someone with English as a
> second language is bad form.

My reply wasn't intended as either, and although it still doesn't seem
that way upon re-reading, offense is in the eye of the beholder, so my
apologies to you both if it was taken that way.

TCP is - and will remain - weak enough for attacks to happen for two
reasons:

	1) attackers need to guess the ports as well as endpoints
	   this is viable for long-lived connections with that
	   persist for long times among widely-known systems

	2) 'widely known' implies infrastructure, which is usually
	   connected at fairly high bandwidth, which means they
	   are susceptible, for other reasons in #1 a well,
	   to "in window" attacks (either ICMP or data injection)

> Strengthening ICMP and TCP where reasonable and possible seem entirely
> sensible to me and in line with the mandate of this workgroup.

If it were, we'd be in the security area, or at least cross-area.
"Strength" means security to me, as does the title of this and some
other drafts, and validity checks don't make a solution solution
"secure" or even "more secure".

Joe
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Oct 2005 08:34:18 +0300 (EEST)

> in many cases even if you try to fix ICMP.

While you as an editor of a WG document may have such an individual 
opinion, I didn't get that impression from the draft, and I'd like to 
see the draft changed if that was the intended tone.

While the TCP's security (not considering ICMPs) is not very strong, I 
do not think it can be classified as "weak" either, especially in 
scenarios where certain insecurities of IP (e.g., source address 
spoofing) can be eliminated.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Sat, 01 Oct 2005 20:51:52 -0700

> see the draft changed if that was the intended tone.

My sentence above should have implied "whether you fix ICMP or not". I
do feel that's the case, but I agree that the doc didn't address that -
mostly because this issue wasn't the focus of that doc.

If it is agreed, I'd be glad to add that or something to that effect.

> spoofing) can be eliminated.

Cases where source address spoofing can be eliminated amount to real
security, either by signatures or by trusted edge filtering.

I would conclude that TCP doesn't have security (because it doesn't),
and that this weakness can be made strong by using real security
(TCP/MD5, IPsec). These help ICMP only where the entire payload is
included in the ICMP reply - which goes back to the point I made earlier
about validation needing to do the same thing, BTW.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Oct 2005 13:25:28 +0300 (EEST)

On Sat, 1 Oct 2005, Joe Touch wrote:
> (TCP/MD5, IPsec).

Ack/seq may not be exactly 'strong', but it's still something. 
Regardless of that 'real security' are generic solutions, and may not 
be needed in all the cases.

> These help ICMP only where the entire payload is

Trusted edge filtering is good security.  An ISP or an enterprise 
could (and in fact _do_) perform that.  Spoofed TCP attacks inside 
such a network are prevented -- but ICMP offers a gaping hole.  Ergo, 
if the IETF believes this scenario is sufficiently common and/or 
convincing, this needs to be fixed (and it may make sense to fix it in 
any case).

It should be obvious, but IMHO this scenario calls for a specific 
solution, not just 'use IPsec'.  A majority of networks have prevented 
spoofing already [http://spoofer.csail.mit.edu/], and internal 
protection from ICMP attacks is required.