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

Fernando Gont wrote:
> At 01:56 17/07/2006, Joe Touch wrote:
> 
>> > 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.
> 
> The counter-measures in the ICMP attacks draft eliminate the ICMP-based
> connection reset, eliminate the Source Quench attack, and require the
> attacker to be a Man In the Middle (*) for him to successfully perform
> an attack against the PMTUD mechanism.

The countermeasures there also violate the specific text in RFC1122,
*without* noting (as per my other email) the "particular circumstances".
Instead, it makes the general recommendation to change hard to soft errors.

I've repeatedly said that the text below directly negates the
requirement in RFC1122. That NEEDS to be directly highlighted in your
doc (the text that says that 1122 allows this is incorrect):

     "For security reasons,
      it would be fair to treat ICMP port unreachable messages as soft
      errors (or completely ignore them) when they are meant for
      protocols that have their own mechanism for reporting this error
      condition."

Again, I'm not going to debate this further either. I'll be glad to
remind the ADs during review; if they agree, fine.

> It is clear that with the ICMP counter-measures in place, TCP-based
> attacks are "the weakest link in the change". You don't need to "drop
> them all".

Even as soft errors, such ICMP errors could be interpreted by the
application as indicating a legitimate error that causes the connection
to be dropped, even though the only reason is attack.

However, perhaps I'm speaking more of what the ICMP draft should be
corrected to be, rather than what it is ;-) Short of changing RFC1122,
you're stuck regarding hard errors and resets, due (notably) to the
DIRECT LANGUAGE in 1122 that equates the two.

Joe

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

Attachment: signature.asc