From matt@advanced.org Tue Jun 6 20:22:49 2000 Received: from betelgeuse.advanced.org ([199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21082 for ; Tue, 6 Jun 2000 20:22:49 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA00816 for ippm-l@advanced.org; Tue, 6 Jun 2000 20:10:46 -0400 (EDT) Received: from smtp.SLAC.Stanford.EDU (SMTP.SLAC.Stanford.EDU [134.79.18.80]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA09145 for ; Tue, 6 Jun 2000 20:10:44 -0400 (EDT) Received: from smtpserv1.SLAC.Stanford.EDU (SMTPSERV1.SLAC.Stanford.EDU [134.79.18.81]) by smtp.slac.stanford.edu (PMDF V5.2-32 #37476) with ESMTP id <0FVR00254CHPBH@smtp.slac.stanford.edu> for ippm@advanced.org; Tue, 6 Jun 2000 17:10:37 -0700 (PDT) Received: from agamemnon.slac.stanford.edu ([134.79.18.86]) by smtpserv1.slac.stanford.edu (PMDF V5.2-32 #37476) with ESMTP id <0FVR00DCXCHO32@smtpserv1.slac.stanford.edu> for ippm@advanced.org; Tue, 06 Jun 2000 17:10:37 -0700 (PDT) Received: by AGAMEMNON.SLAC.Stanford.EDU with Internet Mail Service (5.5.2650.21) id ; Tue, 06 Jun 2000 17:10:33 -0700 Content-return: allowed Date: Tue, 06 Jun 2000 17:10:32 -0700 From: "Cottrell, Les" Subject: Security (SANS) & Monitoring tools To: "'ippm@advanced.org'" Cc: "'security@slac.stanford.edu'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT The FBI, Justice Department, GSA, the CIAO, CERT/CC, SANS and two dozen leading security gurus on Internet Security Threats have created a document on Internet Security Threat. The document is available at the following URL http://www.sans.org/topten.htm I am not sure of the exact status of this document, it is still being updated and Alan Paller the Director of Research of The SANS Institute has said: "I am faced with the following (a) multiple credible people differ on this issue and (b) the security issue and the management issue are in conflict (c) I don't know which one matters more (d) the positions are held almost religiously. I am looking for a community-wide process that could get an answer -- one we could use whenever this type of issue arises. Discussion groups are too often hijacked by zealots who try to win through intimidation. What can we do?" In this document they talk about "Perimeter Protection" where they say "In this section, we list ports that are commonly probed and attacked. Blocking these ports is a minimum requirement for perimeter security, not a comprehensive firewall specification list. A far better rule is to block all unused ports. And even if you believe these ports are blocked, you should still actively monitor them to detect intrusion attempts. A warning is also in order. Blocking some of the ports in the following list may disable needed services. Please consider the potential effects of these recommendations before implementing them." then one of the recommendation is: "ICMP-- block incoming echo request (ping and Windows traceroute), block outgoing echo replies, time exceeded, and unreachable messages". This document has now been provided to ESnet sites by the DoE CIO. It seems to me that this list might have interests in the implications of these recommendations on network monitoring/measurements and trouble shooting. There are other concerns such as breaking MTU discovery (see http://users.worldgate.ca/~marcs/mtu/ ) but they are probably better handled in another mailing list. It should not affect the Surveyor/RIPE type measurements. It will, however, affect AMP, Skitter & PingER measurements if the machines are behind such blocks. It will also affect on the fly trouble-shooting etc. using ping and traceroute. From matt@advanced.org Wed Jun 7 03:44:22 2000 Received: from betelgeuse.advanced.org ([199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07561 for ; Wed, 7 Jun 2000 03:44:22 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id DAA16859 for ippm-l@advanced.org; Wed, 7 Jun 2000 03:36:18 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id DAA14154 for ; Wed, 7 Jun 2000 03:36:16 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 7 Jun 2000 08:36:10 +0100 To: "Cottrell, Les" cc: "'ippm@advanced.org'" , "'security@slac.stanford.edu'" Subject: Re: Security (SANS) & Monitoring tools In-reply-to: Your message of "Tue, 06 Jun 2000 17:10:32 PDT." Date: Wed, 07 Jun 2000 08:36:09 +0100 Message-ID: <7890.960363369@cs.ucl.ac.uk> From: Jon Crowcroft In message , "Cottrell, Les" typed: most of the recommendations are based on 1/ the attack 2/ a documented weakness in a system that the attack exploits in many cases, there are two different actions that can be taken 1/the weakness can be fixed rather than 2/ removing functionality - 1 is better security practice anyhow - obviously some vendors are poor at shipping well tested fixes for sucvh things, so in the real world (TM) one has to fall back on 2 - reduced functionality however, the one below appears not to be accompanied byu a documented weaknness, and imho the reduced functioanlity is therefore not justified. >>"ICMP-- block incoming echo request (ping and Windows traceroute), block >>outgoing echo replies, time exceeded, and unreachable messages". >>This document has now been provided to ESnet sites by the DoE CIO. >>It seems to me that this list might have interests in the implications of >>these recommendations on network monitoring/measurements and trouble >>shooting. There are other concerns such as breaking MTU discovery (see >>http://users.worldgate.ca/~marcs/mtu/ ) but they are probably better handled >>in another mailing list. >>It should not affect the Surveyor/RIPE type measurements. It will, however, >>affect AMP, Skitter & PingER measurements if the machines are behind such >>blocks. It will also affect on the fly trouble-shooting etc. using ping and >>traceroute. >> cheers jon From matt@advanced.org Thu Jun 8 05:19:00 2000 Received: from betelgeuse.advanced.org ([199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10249 for ; Thu, 8 Jun 2000 05:19:00 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id FAA03806 for ippm-l@advanced.org; Thu, 8 Jun 2000 05:03:44 -0400 (EDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id FAA01541 for ; Thu, 8 Jun 2000 05:03:42 -0400 (EDT) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA06307; Thu, 8 Jun 2000 11:03:09 +0200 (CEST) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id LAA12540; Thu, 8 Jun 2000 11:03:08 +0200 (CEST) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 8 Jun 2000 11:03:08 +0200 (CEST) From: "Henk Uijterwaal (RIPE-NCC)" To: "Cottrell, Les" cc: "'ippm@advanced.org'" , "'security@slac.stanford.edu'" Subject: Re: Security (SANS) & Monitoring tools In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 2000, Cottrell, Les wrote: > The FBI, Justice Department, GSA, the CIAO, CERT/CC, SANS and two dozen > leading security gurus on Internet Security Threats have created a document > on Internet Security Threat. The document is available at the following URL > http://www.sans.org/topten.htm I am not sure of the exact status of this > document, it is still being updated and Alan Paller the Director of Research > of The SANS Institute has said: > "I am faced with the following > (a) multiple credible people differ on this issue and > (b) the security issue and the management issue are in conflict > (c) I don't know which one matters more > (d) the positions are held almost religiously. > > I am looking for a community-wide process that could get an answer -- one we > could use whenever this type of issue arises. I'm not sure if there is a correct answer here. The problem appears to be in (b) and (c) above: there is a conflict between security and management, and different sites will come up with a different tradeoff between the two. > It should not affect the Surveyor/RIPE type measurements. For our measurements, we have a list of ports that should be accessible on the box from the outside world and tell people in advance that firewalls (etc.) should be configured accordingly. It's then up to them to decide if they want to do this, if security is more important, well, then we simply cannot do measurements to their site. > It will, however, affect AMP, Skitter & PingER measurements if the > machines are behind such blocks. It will also affect on the fly > trouble-shooting etc. using ping and traceroute. So, for a document like this, I think all one can do is list the arguments why one should or should not block ICMP ports, then leave it up to the site to make the tradeoff. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Thu Jun 8 12:50:44 2000 Received: from betelgeuse.advanced.org ([199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11817 for ; Thu, 8 Jun 2000 12:50:44 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA03929 for ippm-l@advanced.org; Thu, 8 Jun 2000 12:43:27 -0400 (EDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA15234 for ; Thu, 8 Jun 2000 12:43:26 -0400 (EDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00BB0FA6SN@mta5.rcsntx.swbell.net> for ippm@advanced.org; Thu, 8 Jun 2000 11:06:02 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:02 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ippm@advanced.org Message-id: <0FVU00BLEFDZSN@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From matt@advanced.org Fri Jun 9 09:40:53 2000 Received: from betelgeuse.advanced.org ([199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11449 for ; Fri, 9 Jun 2000 09:40:53 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA13882 for ippm-l@advanced.org; Fri, 9 Jun 2000 09:29:03 -0400 (EDT) Received: from access.cc.univie.ac.at (access.cc.univie.ac.at [192.153.174.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with SMTP id JAA15175 for ; Fri, 9 Jun 2000 09:29:01 -0400 (EDT) Received: by cc.univie.ac.at (MX V4.1 VAX) id 19; Fri, 09 Jun 2000 15:28:53 +0200 Date: Fri, 09 Jun 2000 15:28:51 +0200 From: "Wilfried Woeber, UniVie/ACOnet" To: henk@ripe.net CC: ippm@advanced.org, security@SLAC.Stanford.EDU, woeber@cc.univie.ac.at Message-ID: <009EB5AF.E0D0F220.19@cc.univie.ac.at> Subject: Re: Security (SANS) & Monitoring tools Hi Henk, >Subject: Re: Security (SANS) & Monitoring tools > >On Tue, 6 Jun 2000, Cottrell, Les wrote: > >> The FBI, Justice Department, GSA, the CIAO, CERT/CC, SANS and two dozen >> leading security gurus on Internet Security Threats have created a document >> on Internet Security Threat. The document is available at the following URL >> http://www.sans.org/topten.htm I am not sure of the exact status of this >> document, it is still being updated and Alan Paller the Director of Research >> of The SANS Institute has said: >> "I am faced with the following >> (a) multiple credible people differ on this issue and >> (b) the security issue and the management issue are in conflict >> (c) I don't know which one matters more >> (d) the positions are held almost religiously. >> >> I am looking for a community-wide process that could get an answer -- one we >> could use whenever this type of issue arises. > >I'm not sure if there is a correct answer here. The problem appears to be >in (b) and (c) above: there is a conflict between security and management, >and different sites will come up with a different tradeoff between the >two. From a measurement project's point of view, I fully agree with your assessment. At the same time I'm a bit worried about the "general direction" of this discussion and development, i.e. obviously accepting as a given fact that some integral parts of the TCP/IP protocol suite (or better some implementations) can be exploited as vulnerabilities in today's Internet. Simply presenting the options to deal with that as an XOR decision either in favor of a more secure or a more "Internet - style" site might be sending the wrong message to the community. In particular, there might be legal implications in the long run, when the document has used input from entities like FBI, Justice Department, GSA, the CIAO,. I'm missing the solution path (recommendation?) to try to make the "implementations" less vulnerable, either by improving the coding or by tweaking operational parameters, and thus less of an issue. Wilfried. From matt@advanced.org Tue Jun 20 14:12:35 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [199.222.103.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00852 for ; Tue, 20 Jun 2000 14:12:35 -0400 (EDT) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id OAA10371 for ippm-l@advanced.org; Tue, 20 Jun 2000 14:01:05 -0400 (EDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id OAA11732 for ; Tue, 20 Jun 2000 14:00:59 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id OAA00539 for ; Tue, 20 Jun 2000 14:00:28 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA02816; Tue, 20 Jun 2000 14:02:01 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 14:00:27 -0400 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: IPPM WG mailing list Subject: FW: I-D ACTION:draft-cole-sspm-00.txt Date: Tue, 20 Jun 2000 12:28:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFDAD4.91563090" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFDAD4.91563090 Content-Type: text/plain To all: Just wanted to make sure the folks on the ippm mailing list saw this. Our plan is to develop a MIB to enable synthetic probes between remote devices for performance management purposes. We plan to draw heavily from the work in the IPPM WG as discussed in the below draft. Ideally, thru the MIB we could enable the measurements defined in the collect work of the IPPM WG, as well as other application level measurements. Also wanted to let eveyone that, that Randy Presuhn had agreed to allow us to use the disman mailing list for comments and discussions following the rperfman BOF in Adelaide, where this was discussed. Thanks, Bob _____________ Robert G. Cole AT&T Labs, Network Design and Performance Analysis Dept. Tel: (410) 939-8732 FAX: (410) 939-8732 Pager: (888) 858-PAGE, pin 127113 email: rgcole@att.com URL: http://chapman.mt.att.com/ 330 Saint Johns St., 2nd Floor Havre de Grace, MD 21078 USA > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Thursday, June 01, 2000 6:32 AM > To: IETF-Announce; @loki.ietf.org@attrh2.attrh.att.com > Subject: I-D ACTION:draft-cole-sspm-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Framework for Synthetic Sources for Performance > Monitoring > Author(s) : R. Cole, R. Dietz, C. Kalbfleisch > D. Romascanu > Filename : draft-cole-sspm-00.txt > Pages : 26 > Date : 31-May-00 > > This memo discusses the use of synthetic sources (or 'active' probes) > within the context of remote performance monitoring. It discusses > the importance of developing an 'active' probe monitoring capability > within the Internet. It develops a framework for synthetic sources > in performance monitoring against the backdrop of previous, related > work within the IETF. It further reports on the broad agreements > reached in the rperfman BOF held in Adelaide in March 2000 on > furthering work in this area within the IETF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cole-sspm-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-cole-sspm-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-cole-sspm-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. <> ------_=_NextPart_000_01BFDAD4.91563090 Content-Type: message/rfc822 Content-Description: Untitled Attachment To: Subject: Date: Thu, 1 Jun 2000 10:09:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFDAD4.91563090" ------_=_NextPart_002_01BFDAD4.91563090 Content-Type: text/plain ------_=_NextPart_002_01BFDAD4.91563090 Content-Type: application/octet-stream; name="ATT11349" Content-Disposition: attachment; filename="ATT11349" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000531121324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cole-sspm-00.txt ------_=_NextPart_002_01BFDAD4.91563090 Content-Type: message/external-body; site="internet-drafts"; dir="draft-cole-sspm-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BFDAD4.91563090-- ------_=_NextPart_000_01BFDAD4.91563090--