From rpsec-bounces@ietf.org Thu Jun 21 16:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMH-0001tH-0E; Thu, 21 Jun 2007 16:34:25 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1TMG-0001t5-Ba for rpsec-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMG-0001sn-0L for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TME-0006K8-KO for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:23 -0400 Received: from [75.215.104.154] (154.sub-75-215-104.myvzw.com [75.215.104.154]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5LKXsFN004342; Thu, 21 Jun 2007 13:33:54 -0700 (PDT) Message-ID: <467AE0B1.8030300@isi.edu> Date: Thu, 21 Jun 2007 13:33:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [RPSEC] Comments on draft-ietf-rpsec-bgpsecrec-07 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0817995109==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0817995109== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD0E0DBCDB6BA044BC9AE154" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD0E0DBCDB6BA044BC9AE154 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Sorry for the belated reply to this draft; it was only recently brought to the attention of the TCP-MD5 update design team in the TCPM working group. I hope these comments will be useful, and will track responses to this post on the rpsec wg mailing list. Joe ------------------------------------------ Abstract - Securing the info between the parties is not an easy technical matter; if it were, IPsec would be in regular use. The current situation is that TCP-MD5 (created for this purpose) has weaknesses (RFC4808), and that there is IPsec is not used for this (draft-ietf-tcpm-tcp-antispoof). The TCPM WG has created a design team to explore two current proposals (draft-touch-tcpm-tcp-simple-auth, draft-bonica-tcp-auth). 1.2 - "Attacks that do not involve..." is contrary to section 10 pg 15, as well as the abstract itself. 10 - GTSM is not a security mechanism; it is an heuristic that happens to work when tunneling is suitably secured (i.e., when there are uncontrolled tunnels from a host, hopcount checking is useless). IPsec should have been cited, certainly more prominently than GTSM. It's confusing to propose that transport protection "MAY" be a component; BGP without graceful restart treats transport failure as routing failure (as noted in draft-tcpm-tcp-antispoof), and there are substantial problems with graceful restart (as noted in RFC4724), both of which should be summarized here. --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCD0E0DBCDB6BA044BC9AE154 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-DiFrom rpsec-bounces@ietf.org Thu Jun 21 16:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMH-0001tH-0E; Thu, 21 Jun 2007 16:34:25 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1TMG-0001t5-Ba for rpsec-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMG-0001sn-0L for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TME-0006K8-KO for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:23 -0400 Received: from [75.215.104.154] (154.sub-75-215-104.myvzw.com [75.215.104.154]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5LKXsFN004342; Thu, 21 Jun 2007 13:33:54 -0700 (PDT) Message-ID: <467AE0B1.8030300@isi.edu> Date: Thu, 21 Jun 2007 13:33:53 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [RPSEC] Comments on draft-ietf-rpsec-bgpsecrec-07 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0817995109==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0817995109== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCD0E0DBCDB6BA044BC9AE154" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD0E0DBCDB6BA044BC9AE154 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Sorry for the belated reply to this draft; it was only recently brought to the attention of the TCP-MD5 update design team in the TCPM working group. I hope these comments will be useful, and will track responses to this post on the rpsec wg mailing list. Joe ------------------------------------------ Abstract - Securing the info between the parties is not an easy technical matter; if it were, IPsec would be in regular use. The current situation is that TCP-MD5 (created for this purpose) has weaknesses (RFC4808), and that there is IPsec is not used for this (draft-ietf-tcpm-tcp-antispoof). The TCPM WG has created a design team to explore two current proposals (draft-touch-tcpm-tcp-simple-auth, draft-bonica-tcp-auth). 1.2 - "Attacks that do not involve..." is contrary to section 10 pg 15, as well as the abstract itself. 10 - GTSM is not a security mechanism; it is an heuristic that happens to work when tunneling is suitably secured (i.e., when there are uncontrolled tunnels from a host, hopcount checking is useless). IPsec should have been cited, certainly more prominently than GTSM. It's confusing to propose that transport protection "MAY" be a component; BGP without graceful restart treats transport failure as routing failure (as noted in draft-tcpm-tcp-antispoof), and there are substantial problems with graceful restart (as noted in RFC4724), both of which should be summarized here. --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCD0E0DBCDB6BA044BC9AE154 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuCxE5f5cImnZrsRAjj5AJ9LkE9b0IfDPmwrp3JZszFdT9CmOwCfUdXs EqO9ZGajzAhkXX9gRS7YlzU= =W+V3 -----END PGP SIGNATURE----- --------------enigCD0E0DBCDB6BA044BC9AE154-- --===============0817995109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0817995109==-- From rpsec-bounces@ietf.org Thu Jun 21 16:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMH-0001tN-6l; Thu, 21 Jun 2007 16:34:25 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1TMG-0001tC-IQ for rpsec-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMG-0001sz-8h for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TMF-0006KC-RX for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [75.215.104.154] (154.sub-75-215-104.myvzw.com [75.215.104.154]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5LKXwPg004356; Thu, 21 Jun 2007 13:33:58 -0700 (PDT) Message-ID: <467AE0B5.2080104@isi.edu> Date: Thu, 21 Jun 2007 13:33:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505754276==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0505754276== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2519B17D8E6A5CE270D817E7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2519B17D8E6A5CE270D817E7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, The following feedback was requested on the TCPM's TCP-AUTH-DT (TCP-Auth design team) mailing list. TCP-Auth is TCMP's work towards an update to TCP-MD5, based on two current proposals (noted below). Joe --------------------------------------------- This document appears to overlap ongoing work in TCPM to characterize concerns with using TCP-MD5 to secure BGP, and use of alternatives. E.g., draft-ietf-tcpm-antispoof. The TCP-Auth team is currently workiing to revise draft-bellovin-tcpsec, and an update to that should be out shortly. Some additional comments: Sec 1 - the OSI stack is not the reference model for the Internet. GTSM is not IP layer security; it is a heuristic that checks TTLs in IP packets, and assumes that there is other security protecting tunnels to a host. It would be more appropriate to cite IPsec as IP security, and GTSM as "other protection mechanisms". Other work in this area: - draft-ietf-tcpm-antispoof (as noted above) - draft-ietf-tcpm-tcpsecure - draft-bellovin-tcpsposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuCxE5f5cImnZrsRAjj5AJ9LkE9b0IfDPmwrp3JZszFdT9CmOwCfUdXs EqO9ZGajzAhkXX9gRS7YlzU= =W+V3 -----END PGP SIGNATURE----- --------------enigCD0E0DBCDB6BA044BC9AE154-- --===============0817995109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0817995109==-- From rpsec-bounces@ietf.org Thu Jun 21 16:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMH-0001tN-6l; Thu, 21 Jun 2007 16:34:25 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1TMG-0001tC-IQ for rpsec-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TMG-0001sz-8h for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TMF-0006KC-RX for rpsec@ietf.org; Thu, 21 Jun 2007 16:34:24 -0400 Received: from [75.215.104.154] (154.sub-75-215-104.myvzw.com [75.215.104.154]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5LKXwPg004356; Thu, 21 Jun 2007 13:33:58 -0700 (PDT) Message-ID: <467AE0B5.2080104@isi.edu> Date: Thu, 21 Jun 2007 13:33:57 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0505754276==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0505754276== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2519B17D8E6A5CE270D817E7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2519B17D8E6A5CE270D817E7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, The following feedback was requested on the TCPM's TCP-AUTH-DT (TCP-Auth design team) mailing list. TCP-Auth is TCMP's work towards an update to TCP-MD5, based on two current proposals (noted below). Joe --------------------------------------------- This document appears to overlap ongoing work in TCPM to characterize concerns with using TCP-MD5 to secure BGP, and use of alternatives. E.g., draft-ietf-tcpm-antispoof. The TCP-Auth team is currently workiing to revise draft-bellovin-tcpsec, and an update to that should be out shortly. Some additional comments: Sec 1 - the OSI stack is not the reference model for the Internet. GTSM is not IP layer security; it is a heuristic that checks TTLs in IP packets, and assumes that there is other security protecting tunnels to a host. It would be more appropriate to cite IPsec as IP security, and GTSM as "other protection mechanisms". Other work in this area: - draft-ietf-tcpm-antispoof (as noted above) - draft-ietf-tcpm-tcpsecure - draft-bellovin-tcpsec as well as specific proposals to update TCP-MD5: - draft-touch-tcpm-tcp-simple-auth - draft-bonica-tcp-auth Further, to a large extent, the preference of router managers to avoid IPsec was the motivation behind BTNS: - http://www.ietf.org/html.charters/btns-charter.html See also the problem and applicability statement: - draft-ietf-btns-prob-and-applic draft-bellovin-tcpsec should be cited in "Dependence on the MD5 algorithm...", as well as RFC4808 3.2 - IPsec =3D RFC4301 in addition to Bonica's proposed alternative, please include mine ;-) = : draft-touch-tcpm-tcp-simple-auth 3.3 - "This requirement is currently..." - also by IPsec. --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig2519B17D8E6A5CE270D817E7 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuC1E5f5cImnZrsRArXCAJ9jLSFwoQq0vnol0f+CRTlI4JmBcwCg0fyT LPlKut92F0KYdHt+Hb+ArMI= =t1pU -----END PGP SIGNATURE----- --------------enig2519B17D8E6A5CE270D817E7-- --===============0505754276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0505754276==-- sec as well as specific proposals to update TCP-MD5: - draft-touch-tcpm-tcp-simple-auth - draft-bonica-tcp-auth Further, to a large extent, the preference of router managers to avoid IPsec was the motivation behind BTNS: - http://www.ietf.org/html.charters/btns-charter.html See also the problem and applicability statement: - draft-ietf-btns-prob-and-applic draft-bellovin-tcpsec should be cited in "Dependence on the MD5 algorithm...", as well as RFC4808 3.2 - IPsec =3D RFC4301 in addition to Bonica's proposed alternative, please include mine ;-) = : draft-touch-tcpm-tcp-simple-auth 3.3 - "This requirement is currently..." - also by IPsec. --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig2519B17D8E6A5CE270D817E7 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeuC1E5f5cImnZrsRArXCAJ9jLSFwoQq0vnol0f+CRTlI4JmBcwCg0fyT LPlKut92F0KYdHt+Hb+ArMI= =t1pU -----END PGP SIGNATURE----- --------------enig2519B17D8E6A5CE270D817E7-- --===============0505754276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0505754276==-- From rpsec-bounces@ietf.org Fri Jun 22 09:31:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jEK-0004AG-BQ; Fri, 22 Jun 2007 09:31:16 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1jEJ-0004AB-1w for rpsec-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 09:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jEI-0004A2-Ob for rpsec@ietf.org; Fri, 22 Jun 2007 09:31:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jEI-00088G-CX for rpsec@ietf.org; Fri, 22 Jun 2007 09:31:14 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2007 06:31:14 -0700 X-IronPort-AV: i="4.16,451,1175497200"; d="scan'208"; a="170224759:sNHT47415312" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5MDVD1f015463; Fri, 22 Jun 2007 06:31:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5MDVDGW005434; Fri, 22 Jun 2007 13:31:13 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 06:31:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 Date: Fri, 22 Jun 2007 06:31:13 -0700 Message-ID: In-Reply-To: <467AE0B5.2080104@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 Thread-Index: Ace0Q5LX664kpNjVTfiM6QHBRd0VtQASytRw References: <467AE0B5.2080104@isi.edu> From: "Barry Greene \(bgreene\)" To: "Joe Touch" , X-OriginalArrivalTime: 22 Jun 2007 13:31:13.0624 (UTC) FILETIME=[9A7A9D80:01C7B4D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2450; t=1182519073; x=1183383073; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=20=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:=20RE=3A=20[RPSEC]=20Feedback=20on=20draft-behringer-bgp-session -req-01 |Sender:=20; bh=LKMkg9UJCzqfqx6UKZQDEJness0YvTUE00HVEYfLM/U=; b=LYadufgP7AJ1191YE5nLqTByPMnIMT3O7FzX8yu/W/XS01B0mtS+RLpO/2TShfjdDuLFAYxQ uZzU9mZcWXEe/frXHmRkOVwgiQqVldk/AZX0GeIfslwYPLxgMq+u6qzl; Authentication-Results: sj-dkim-4; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org I guess we have differing views on the definition of "security." If I can classify based on a policy which provides me more resistance from attacks, then that is a "security tool." Hence, GTSM is a security tool. > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Thursday, June 21, 2007 1:34 PM > To: rpsec@ietf.org > Subject: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 >=20 > Hi, all, >=20 > The following feedback was requested on the TCPM's=20 > TCP-AUTH-DT (TCP-Auth design team) mailing list. TCP-Auth is=20 > TCMP's work towards an update to TCP-MD5, based on two=20 > current proposals (noted below). >=20 > Joe >=20 > --------------------------------------------- >=20 > This document appears to overlap ongoing work in TCPM to=20 > characterize concerns with using TCP-MD5 to secure BGP, and=20 > use of alternatives. > E.g., draft-ietf-tcpm-antispoof. The TCP-Auth team is=20 > currently workiing to revise draft-bellovin-tcpsec, and an=20 > update to that should be out shortly. >=20 > Some additional comments: >=20 > Sec 1 - the OSI stack is not the reference model for the Internet. > GTSM is not IP layer security; it is a heuristic that checks=20 > TTLs in IP packets, and assumes that there is other security=20 > protecting tunnels to a host. It would be more appropriate to=20 > cite IPsec as IP security, and GTSM as "other protection mechanisms". >=20 > Other work in this area: > - draft-ietf-tcpm-antispoof (as noted above) > - draft-ietf-tcpm-tcpsecure > - draft-bellovin-tcpsec > as well as specific proposals to update TCP-MD5: > - draft-touch-tcpm-tcp-simple-auth > - draft-bonica-tcp-auth >=20 > Further, to a large extent, the preference of router managers=20 > to avoid IPsec was the motivation behind BTNS: > - http://www.ietf.org/html.charters/btns-charter.html > See also the problem and applicability statement: > - draft-ietf-btns-prob-and-applic >=20 > draft-bellovin-tcpsec should be cited in "Dependence on the=20 > MD5 algorithm...", as well as RFC4808 >=20 > 3.2 - IPsec =3D RFC4301 > in addition to Bonica's proposed alternative, please include=20 > mine ;-) : > draft-touch-tcpm-tcp-simple-auth >=20 > 3.3 - "This requirement is currently..." - also by IPsec. >=20 > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment >=20 >=20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jun 22 10:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k1E-0001rN-CG; Fri, 22 Jun 2007 10:21:48 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1k1D-0001rI-Dq for rpsec-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 10:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k1D-0001r9-4E for rpsec@ietf.org; Fri, 22 Jun 2007 10:21:47 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1k1A-0003YV-Kx for rpsec@ietf.org; Fri, 22 Jun 2007 10:21:47 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l5MELIoQ006737; Fri, 22 Jun 2007 07:21:18 -0700 (PDT) Message-ID: <467BDADD.3000406@isi.edu> Date: Fri, 22 Jun 2007 07:21:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 References: <467AE0B5.2080104@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.1 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957386417==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0957386417== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1D3AB5BCF55D129E9BDB950" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1D3AB5BCF55D129E9BDB950 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Barry, Barry Greene (bgreene) wrote: > I guess we have differing views on the definition of "security." If I > can classify based on a policy which provides me more resistance from > attacks, then that is a "security tool." Hence, GTSM is a security tool= =2E GTSM could be classified as a security tool, but it is not IP layer security. It is a mechanism an endpoint can use to increase its resistance to attack, as you note, but it doesn't particularly protect any single protocol layer or header. Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Thursday, June 21, 2007 1:34 PM >> To: rpsec@ietf.org >> Subject: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 >> >> Hi, all, >> >> The following feedback was requested on the TCPM's=20 >> TCP-AUTH-DT (TCP-Auth design team) mailing list. TCP-Auth is=20 >> TCMP's work towards an update to TCP-MD5, based on two=20 >> current proposals (noted below). >> >> Joe >> >> --------------------------------------------- >> >> This document appears to overlap ongoing work in TCPM to=20 >> characterize concerns with using TCP-MD5 to secure BGP, and=20 >> use of alternatives. >> E.g., draft-ietf-tcpm-antispoof. The TCP-Auth team is=20 >> currently workiing to revise draft-bellovin-tcpsec, and an=20 >> update to that should be out shortly. >> >> Some additional comments: >> >> Sec 1 - the OSI stack is not the reference model for the Internet. >> GTSM is not IP layer security; it is a heuristic that checks=20 >> TTLs in IP packets, and assumes that there is other security=20 >> protecting tunnels to a host. It would be more appropriate to=20 >> cite IPsec as IP security, and GTSM as "other protection mechanisms". >> >> Other work in this area: >> - draft-ietf-tcpm-antispoof (as noted above) >> - draft-ietf-tcpm-tcpsecure >> - draft-bellovin-tcpsec >> as well as specific proposals to update TCP-MD5: >> - draft-touch-tcpm-tcp-simple-auth >> - draft-bonica-tcp-auth >> >> Further, to a large extent, the preference of router managers=20 >> to avoid IPsec was the motivation behind BTNS: >> - http://www.ietf.org/html.charters/btns-charter.html >> See also the problem and applicability statement: >> - draft-ietf-btns-prob-and-applic >> >> draft-bellovin-tcpsec should be cited in "Dependence on the=20 >> MD5 algorithm...", as well as RFC4808 >> >> 3.2 - IPsec =3D RFC4301 >> in addition to Bonica's proposed alternative, please include=20 >> mine ;-) : >> draft-touch-tcpm-tcp-simple-auth >> >> 3.3 - "This requirement is currently..." - also by IPsec. >> >> -- >> ---------------------------------------- >> Joe Touch >> Sr. Network Engineer, USAF TSAT Space Segment --------------enigB1D3AB5BCF55D129E9BDB950 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.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGe9rdE5f5cImnZrsRAml0AKDC0VtquzrK1S4oplqQmWVgG368qwCg0CUw qWGhgY2qrpMPM4ByJieN+w0= =kX14 -----END PGP SIGNATURE----- --------------enigB1D3AB5BCF55D129E9BDB950-- --===============0957386417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0957386417==-- From rpsec-bounces@ietf.org Fri Jun 22 12:07:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lfH-0004cr-Tj; Fri, 22 Jun 2007 12:07:15 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1lfG-0004cZ-00 for rpsec-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 12:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1lfF-0004cO-Mm for rpsec@ietf.org; Fri, 22 Jun 2007 12:07:13 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1lfE-0003AV-GV for rpsec@ietf.org; Fri, 22 Jun 2007 12:07:13 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I1lfD-0000tY-69; Fri, 22 Jun 2007 12:07:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <467BDADD.3000406@isi.edu> References: <467AE0B5.2080104@isi.edu> <467BDADD.3000406@isi.edu> Date: Fri, 22 Jun 2007 11:10:40 -0400 To: Joe Touch From: Stephen Kent Subject: Re: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Barry Greene \(bgreene\)" , rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 7:21 AM -0700 6/22/07, Joe Touch wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enigB1D3AB5BCF55D129E9BDB950" > >Hi, Barry, > >Barry Greene (bgreene) wrote: >> I guess we have differing views on the definition of "security." If I >> can classify based on a policy which provides me more resistance from >> attacks, then that is a "security tool." Hence, GTSM is a security tool. > >GTSM could be classified as a security tool, but it is not IP layer >security. It is a mechanism an endpoint can use to increase its >resistance to attack, as you note, but it doesn't particularly protect >any single protocol layer or header. > >Joe GTSM also has a very limited (although important) scope, since it is generally applicable only in contexts where one can predict the appropriate TTL value for legitimate traffic (and where active attacks on the path the traffic is traversing are not assumed to be viable). Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jun 22 13:02:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mWd-0004Ds-7n; Fri, 22 Jun 2007 13:02:23 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I1mWc-0004Dn-PZ for rpsec-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 13:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1mWc-0004Df-G8 for rpsec@ietf.org; Fri, 22 Jun 2007 13:02:22 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1mWa-00079h-5u for rpsec@ietf.org; Fri, 22 Jun 2007 13:02:22 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 22 Jun 2007 10:02:19 -0700 Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 13:02:18 -0400 Message-ID: <467C0094.3070900@juniper.net> Date: Fri, 22 Jun 2007 13:02:12 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] Feedback on draft-behringer-bgp-session-req-01 References: <467AE0B5.2080104@isi.edu> <467BDADD.3000406@isi.edu> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 17:02:18.0408 (UTC) FILETIME=[17474A80:01C7B4EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Barry Greene \(bgreene\)" , rpsec@ietf.org, Joe Touch X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Folks, I think that the following word might be useful as we discuss the proper classification of GTSM within the taxonomy of security mechanisms: http://www.worldwidewords.org/weirdwords/ww-tet1.htm all in good fun ;-) Ron Stephen Kent wrote: > At 7:21 AM -0700 6/22/07, Joe Touch wrote: > >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enigB1D3AB5BCF55D129E9BDB950" >> >> Hi, Barry, >> >> Barry Greene (bgreene) wrote: >> >>> I guess we have differing views on the definition of "security." If I >>> can classify based on a policy which provides me more resistance from >>> attacks, then that is a "security tool." Hence, GTSM is a security >>> tool. >> >> >> GTSM could be classified as a security tool, but it is not IP layer >> security. It is a mechanism an endpoint can use to increase its >> resistance to attack, as you note, but it doesn't particularly protect >> any single protocol layer or header. >> >> Joe > > > > GTSM also has a very limited (although important) scope, since it is > generally applicable only in contexts where one can predict the > appropriate TTL value for legitimate traffic (and where active attacks > on the path the traffic is traversing are not assumed to be viable). > > Steve > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec