Message-ID: <47F9AB92.80405@isi.edu>
Date: Sun, 06 Apr 2008 22:05:22 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <200804041832.m34IWTC5025090@venus.xmundo.net>
 <47F68794.6050100@isi.edu>
 <200804042012.m34KCk8U022643@venus.xmundo.net>
 <47F68DC7.2050303@isi.edu>
 <200804050557.m355vAjU013266@venus.xmundo.net>
 <47F7B43E.6010004@isi.edu>
 <200804052024.m35KOlmj018418@venus.xmundo.net>
 <47F7E2D0.8010802@isi.edu>
 <200804052353.m35NrdO1031661@venus.xmundo.net>
 <47F82129.2000603@isi.edu>
 <200804061042.m36AgYGx028003@venus.xmundo.net>
 <47F92D13.4020809@isi.edu>
 <200804062241.m36MfGKx010325@venus.xmundo.net>
In-Reply-To: <200804062241.m36MfGKx010325@venus.xmundo.net>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Some comments on tcpsecure
Precedence: list
Content-Type: multipart/mixed; boundary="===============1283681700=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1283681700==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7C8B9831D58BB4C89212298C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7C8B9831D58BB4C89212298C
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable



Fernando Gont wrote:
> At 05:05 p.m. 06/04/2008, Joe Touch wrote:
>=20
> (Meta comment: The current version of the ICMP attacks draft is meant=20
> for the Informational path. I believe I have removed/rephrased those=20
> senteces which seemed to "propose" the mitigation-techniques, rather=20
> than simply document them. If I did a good job in this last revision,=20
> the doc shouldn't be far from being ready to be shipped to the IESG. Th=
e=20
> soft errors draft is already there. These two drafts, together with=20
> another one some of us will be submitting anytime soon would be of grea=
t=20
> help as a basis for further work that would include what you sketch=20
> bellow.)
>=20
> Please see my comments inline....
>=20
>=20
>> Let's try to move this forward constructively...
>=20
> Agreed.
>=20
>=20
> [....]
>>         I do believe we need to make this work in the case of
>>         non-malicious behavior. Only then should we consider
>>         whether or not it affords obfuscation protection against
>>         attackers.
>>
>>         Given this case, then *progress* is the metric. That implies:
>>                 - cache received ICMPs and log window state
>>                 - determine if the window moves after the ICMP
>>                 is received; if so, drop that ICMP
>=20
> (Thinking out loud, with no coffee in the last few hours ;-) ): I'd als=
o=20
> add "Discard the ICMP message if there's no data in flight to the=20
> destination when the ICMP error message is received" (i.e., in such a=20
> scenario, there's no "forward progress" to be made).

OK - again, that has nothing to do with the contents of the ICMP message.=


>> One key issue above: it is NOT dependent on the window data in the=20
>> ICMP payload, for two reasons:
>>
>>         1) (my point) ICMPs are not required to be issued in a timely
>>         fashion, or for every individual error, a legitimate situation=

>>         could involve receiving an old ICMP about an endpoint failure,=

>>         without receiving further updates on any particular schedule
>>
>>         2) (Fernando's point) ICMPs are currently implemented widely
>>         as not being issued in a timely fashion, with the same results=

>>         as #1
>>
>> I.e., it doesn't matter if you design for spec or common=20
>> implementations; either way, ICMP payload window information is not=20
>> relevant to the "making progress" issue.
>=20
> Agreed. You may say "making progress" and "requiring the TCP SEQ in the=
=20
> ICMP payload to be 'in-window'" are two different issues.

Agreed.

> The TCP SEQ check would help a bit in those scenarios in which an=20
> attacker might be able to spoof an ICMP error message, and cause the=20
> connection to be stuck for a little while (e.g., by means of causing=20
> congestion). That is, it would require more packets on the side of the =

> attacker.

In those cases, I still see the contents of the ICMP to be moot (w.r.t.=20
window). That info is useful only if:
	- ICMPs are known to be returned in a timely fashion
	(and there's no way of knowing)
	OR
	- there's some way to differentiate between legitimate
	ICMPs and attack ICMPs

Since neither is the case, this is a moot issue. I do not agree that=20
checking the TCP SEQ in the content of an ICMP is ever appropriate.
=09
> However, if TCP waits for USER_TIMEOUT to check whether the connection =

> is making forward progress, then this is basically the "hard errors=20
> should be considered to indicate soft errors when received for=20
> connections in any of the synchronized states" behavior, and thus an=20
> attacker could not exploit the so-called ICMP hard errors to perform=20
> reset attacks.

Waiting that long defeats the purpose of the errors - to terminate=20
connections more rapidly than TCP would otherwise. That is, IMO, too far.=


> (i.e., the "hard errors should be considered to indicate soft errors=20
> when received for connections in any of the synchronized states" become=
s=20
> a degenerate case of the "checking for progress on the TCP connection" =

> when TCP waits for USER_TIMEOUT seconds before concluding whether the=20
> connection is making progress or not).
>=20
> (FWIW, the TCP SEQ is of a little bit more of help for PMTUD, as during=
=20
> what I called 'Initial Path-MTU Discovery', you probably don't want to =

> wait, so that you get a good convergence time for the PMTUD).

I'd have to think further to see if this appropriate - i.e., if done=20
only once during a connection, before a wrap, then the SEQ might be=20
appropriate to check, but only within that period.

Joe


--------------enig7C8B9831D58BB4C89212298C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+auSE5f5cImnZrsRAi4JAJ9uLDMH/NYR6gDdWEGDmoZKplr8EACdH8WI
KaDSe5Tvesu0y5QR6Kc+AuA=
=alMe
-----END PGP SIGNATURE-----

--------------enig7C8B9831D58BB4C89212298C--

--===============1283681700==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--===============1283681700==--