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

Joe Touch <touch@ISI.EDU> Tue, 18 July 2006 21:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x3i-0001OU-4k; Tue, 18 Jul 2006 17:24:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x3g-0001OP-Fp for tcpm@ietf.org; Tue, 18 Jul 2006 17:24:48 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2x3f-0000oR-3K for tcpm@ietf.org; Tue, 18 Jul 2006 17:24:48 -0400
Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6ILNWH01843; Tue, 18 Jul 2006 14:23:32 -0700 (PDT)
Message-ID: <44BD514C.2090704@isi.edu>
Date: Tue, 18 Jul 2006 14:23:24 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] feedcback on tcp-secure-05
References: <0C53DCFB700D144284A584F54711EC5801D9592B@xmb-sjc-21c.amer.cisco.com> <7.0.1.0.0.20060715153423.08601b58@gont.com.ar> <44BB1882.6030904@isi.edu> <7.0.1.0.0.20060717052818.064b28b8@gont.com.ar> <44BCE4FA.1050602@isi.edu> <7.0.1.0.0.20060718160252.066880d8@gont.com.ar>
In-Reply-To: <7.0.1.0.0.20060718160252.066880d8@gont.com.ar>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1368961918=="
Errors-To: tcpm-bounces@ietf.org


Fernando Gont wrote:
> At 10:41 18/07/2006, Joe Touch wrote:
> 
> [Talking about the ICMP attacks draft]
> 
>> 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."
> 
> Joe, this already was in my list of changes. There are a bunch of
> comments from Mark, Pyda, Fred, you and others that I will (hopefully)
> address in the next revision of the draft.
> 
> Now, as per Anatha's e-mails, there's ambiguity in RFC 1122 respect to
> this issue. There's a MUST and a SHOULD on the issue of what is supposed
> to be the correct reaction to a port unreachable.
> 
> So, would you agree with the draft mentioning the ambiguity, and, as in
> the case of the other ICMP error codes, stating why it would make sense
> to treat them as soft errors, instead? (The "SHOULD" allows for that,
> after all).

The specific reason and conditions for the SHOULD *must* (my must) be
addressed, IMO (presumably "connect established" at least, or making
forward progress at most - with caveats about change of behavior - for
better or worse - in certain multipath scenarios as already raised).

The existence of the ambiguity *must* also be specifically noted.

If these are already repeating previous conclusions, that's 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.
> 
> This assumes that:
> a) The system in question does not honor the "recommendation" in the
> ICMP attacks draft

You're making recommendations about what the TCP should do regarding the
errors; that's not the same as what the application on top of TCP would do.

> b) ICMP error messages are passed to the application. In the Sockets
> API, they are passed only after a USER TIMEOUT.

I don't recall anything in 1122 about how quickly soft errors must be
passed to the app, but they MUST be passed to the app. This implies that
soft errors aren't passed if a user timeout doesn't occur, which seems
like another violation that should be noted.

Joe

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