Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 8 Jan 2008 08:37:20 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC5804830AB1@xmb-sjc-21c.amer.cisco.com>
Thread-Topic: TCP secure 
Thread-Index: AchOTGxU+YLeyjV5T12k8IIaALueMADx7/xA
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "TCP Maintenance and Minor Extensions WG" <tcpm@ietf.org>
Cc: Ted Faber <faber@isi.edu>, mallman@icir.org
Subject: [tcpm] RE: TCP secure 
Precedence: list
Errors-To: tcpm-bounces@ietf.org


More latest developments on this. Since the draft was expiring on Jan
9th, I had to post a new version to renew the draft which should show up
in the usual places very soon. This version has :-

- The Applicability statement in place (section 1.1)=20
- Alfred Hoenes had some editorial comments on the previous version,
incorporated them.

You can use the AS in the draft as a reference for discussions
pertaining to the same.

Thanks,
Anantha

> -----Original Message-----
> From: Anantha Ramaiah (ananth)=20
> Sent: Thursday, January 03, 2008 1:06 PM
> To: TCP Maintenance and Minor Extensions WG
> Cc: 'mallman@icir.org'; Ted Faber
> Subject: TCP secure=20
>=20
> Greetings,
>       =20
> The following note pertains to the TCP secure document and=20
> the hope is to get this to WGLC once the pending issues are resolved.
>=20
> Summary
> =3D=3D=3D=3D=3D=3D=3D
>=20
> After the presentation in the Chicago IETF and the follow up=20
> discussions on the mailing list w.r.t the strength of the=20
> mitigations, the outcome of which was to have an=20
> applicability statement and then go about getting consensus=20
> on the strength of each individual mitigation. To quote Mark Allman :
>=20
> <BEGIN QUOTE>
>=20
>   It seems to me that this discussion is really divergent=20
> because there
>   is no applicability statement in the document, per Lars' comment.  I
>   wonder if you guys could go off and generate such a=20
> statement and then
>   we could re-visit this question.  I think that would factor things
>   into a question of "where" this is applicable and then how=20
> strongly we
>   want to advocate these mitigations within that context.  Is that
>   reasonable?
>=20
> <END QUOTE>
>=20
> There was a discussion in which some folks mentioned how the=20
> AS should be structured. We have attempted to capture this=20
> and what follows is the sample AS.
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> APPLICABILITY STATEMENT
>=20
> The mitigations presented in this document talks about some=20
> known in-window attacks and the solutions to the same. The=20
> mitigations suggested in this draft SHOULD (RECOMMENDED) be=20
> implemented in devices where the TCP connections are most=20
> vulnerable to the attacks described in this document.  Some=20
> examples of such TCP connections are the ones that tend to be=20
> long-lived where the connection end points can be determined,=20
> in cases where no auxiliary anti-spoofing protection=20
> mechanisms like TCP MD5 can be deployed. TCP secure MAY=20
> (OPTIONAL) be implemented in other cases.=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>=20
> It would be nicer if folks can comment on the=20
>=20
> A) AS and suggest any modifications.
>=20
> B) choose the strength of each mitigation WITH reasoning.
>=20
>=20
> My vote
> =3D=3D=3D=3D=3D=3D=3D
>=20
> Since AS covers the main concern, my vote would go for all=20
> MUST's or SHOULD's.
>=20
> Reason for picking MUST's or SHOULD's :=20
>=20
> With AS in place, the document has given enough leeway for=20
> implementers to pick and chose whether one wants to implement=20
> TCP secure or not. These mitigations are important since it=20
> increases TCP's robustness to various attacks described in=20
> the document. Hence I would color them as MUST's or SHOULD's.
>=20
> Thanks,
> Anantha
>=20


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm