From owner-Big-Internet@munnari.OZ.AU Tue Nov 1 04:48:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19867; Tue, 1 Nov 1994 04:16:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA29972; Tue, 1 Nov 1994 04:11:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29969; Tue, 1 Nov 1994 04:07:20 +1100 Precedence: list Received: from sirius.ctr.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18428; Tue, 1 Nov 1994 03:30:15 +1100 (from hiroshi@ctr.columbia.edu) Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20389; Mon, 31 Oct 1994 09:01:17 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14424; Mon, 31 Oct 1994 09:01:15 -0500 Date: Mon, 31 Oct 1994 09:01:15 -0500 Message-Id: <199410311401.JAA14424@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of New Mailing-List Creation Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 1 04:48:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20135; Tue, 1 Nov 1994 04:27:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA29994; Tue, 1 Nov 1994 04:27:16 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29966; Tue, 1 Nov 1994 04:04:14 +1100 Precedence: list Received: from sirius.ctr.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17826; Tue, 1 Nov 1994 03:09:52 +1100 (from hiroshi@ctr.columbia.edu) Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20913; Mon, 31 Oct 1994 09:40:39 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14662; Mon, 31 Oct 1994 09:40:36 -0500 Date: Mon, 31 Oct 1994 09:40:36 -0500 Message-Id: <199410311440.JAA14662@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip-atm@necom830.cc.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of new mailing-list (correction) Dear for the persons who are interested in a new mailing-list (colip), ***** I wrote a wrong addresses for mailing-list (:-|) ***** The below is the correct one. We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- >> General Discussion: colip-atm@necom830.cc.titech.ac.jp >> To subscribe: colip-atm-request@necom830.cc.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 1 07:49:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24200; Tue, 1 Nov 1994 06:55:01 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00140; Tue, 1 Nov 1994 06:52:01 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00135; Tue, 1 Nov 1994 06:36:05 +1100 Precedence: list Received: from sirius.ctr.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23739; Tue, 1 Nov 1994 06:35:46 +1100 (from hiroshi@ctr.columbia.edu) Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20487; Mon, 31 Oct 1994 09:14:44 -0500 From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14496; Mon, 31 Oct 1994 09:14:42 -0500 Date: Mon, 31 Oct 1994 09:14:42 -0500 Message-Id: <199410311414.JAA14496@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.Eng.Sun.COM, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.OZ.AU Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of New Mailing-List Creation Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- From owner-Big-Internet@munnari.OZ.AU Wed Nov 2 00:53:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28752; Wed, 2 Nov 1994 00:53:22 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00313; Wed, 2 Nov 1994 00:52:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA00299; Wed, 2 Nov 1994 00:35:27 +1100 Precedence: list Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28241; Wed, 2 Nov 1994 00:35:04 +1100 (from bcruucp@thumper.bellcore.com) Received: (from bcruucp@localhost) by thumper.bellcore.com (8.6.9/8.6.6) id IAA24495 for Big-Internet@munnari.OZ.AU; Tue, 1 Nov 1994 08:34:58 -0500 Date: Tue, 1 Nov 1994 08:34:58 -0500 Message-Id: <199411011334.IAA24495@thumper.bellcore.com> Subject: abel has new e-mail address From: PostMaster@Bellcore.COM Apparently-To: Big-Internet@munnari.OZ.AU This is to notify you that abel is no longer at this address: (s)he can now be reached at AWeinrib@ibeam.intel.com. Please update your information reguarding this individual. Thank you John Walden Postmaster@bellcore.com ============================================================== From owner-Big-Internet@munnari.OZ.AU Tue Nov 1 08:34:54 1994 Received: from flash.bellcore.com (flash.bellcore.com [128.96.32.20]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id IAA24474 for ; Tue, 1 Nov 1994 08:34:53 -0500 Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by flash.bellcore.com (8.6.9/8.6.4) with ESMTP id IAA26102 for ; Tue, 1 Nov 1994 08:34:47 -0500 Received: by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00292; Wed, 2 Nov 1994 00:20:07 +1100 Date: Wed, 2 Nov 1994 00:20:07 +1100 Precedence: list From: Big-Internet@munnari.OZ.AU Reply-To: Big-Internet@munnari.OZ.AU Subject: Big Internet Digest [4.1] To: Big-Internet-Digest-List:; Message-ID: Big Internet Digest Volume 4 Number 1 Of Tuesday, 1st November, 1994 Subjects in today's digest (sorted) ... Announcement of new mailing-list (correction) ------------ From: hiroshi@ctr.columbia.edu (Hiroshi Esaki) Date: Mon, 31 Oct 1994 09:40:36 -0500 Message-Id: <199410311440.JAA14662@mimas.ctr.columbia.edu> Subject: Announcement of new mailing-list (correction) Dear for the persons who are interested in a new mailing-list (colip), ***** I wrote a wrong addresses for mailing-list (:-|) ***** The below is the correct one. [ Two copies of incorrect message deleted from B-I-Digest ... kre ] We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- >> General Discussion: colip-atm@necom830.cc.titech.ac.jp >> To subscribe: colip-atm-request@necom830.cc.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ---------------------- ------------ This has been a (usually daily) digested form of the Big-Internet list. Send messages for the list to Big-Internet@munnari.OZ.AU Please do not reply to this message, the subject would be meaningless to anyone not getting the digest form of the list, and not very specific in any case. Please construct a new message with an appropriate subject. Send administrative requests (in any comprehensible form of English) to Big-Internet-Request@munnari.OZ.AU Big Internet Digest Volume 4 Number 1 Of Tuesday, 1st November, 1994 From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 06:16:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01326; Thu, 3 Nov 1994 03:37:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA01681; Thu, 3 Nov 1994 03:32:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA01676; Thu, 3 Nov 1994 03:30:12 +1100 Precedence: list Received: from cheops.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01471; Thu, 3 Nov 1994 02:40:33 +1100 (from avalon@coombs.anu.edu.au) Message-Id: <9411021540.1471@munnari.oz.au> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA22555; Thu, 3 Nov 94 02:38:15 +1100 From: Darren Reed Subject: Re: Concerns about MAC spoofing (fwd) To: big-internet@munnari.OZ.AU Date: Thu, 3 Nov 1994 02:38:14 +1100 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2198 For those who have been/were wondering about ethernet addresses being unique, coming from the manufacturer and desiring to use the IEEE 802 numbers as part of the EID, the following letter from the firewalls mailing list should remove any doubt about how useful/useless this is. Unless PCs weren't being thought of at the time and/or not being desired as part of IPng :-) Darren Forwarded message: > From firewalls-owner@GreatCircle.COM Thu Nov 3 02:13:14 1994 > Date: Wed, 2 Nov 1994 08:48:45 -0500 (EST) > From: David Miller > Subject: Re: Concerns about MAC spoofing > To: Rich=Gautier%SP-23DC%DRC@S1.drc.com > Message-Id: > > On Wed, 2 Nov 1994 Rich=Gautier%SP-23DC%DRC@S1.drc.com wrote: > > > I have a few questions about MAC spoofing. First off, how difficult would it > > be to spoof a MAC address in a non-TCP/IP environment (i.e. IPX/SPX?). > > Without an IFCONFIG, wouldn't the user require a hacked copy of the MLID to > > do this? > > It's pretty trivial in a PC environment. Virtually all the drivers now > allow you to set the mac address to anything you want. This can be a > useful feature, particularly if you want to run bootp. > > > > > Secondly, what happens if two cards exist with same MAC address on a network? > > Does it lock up both cards, or do the two cards start sending garbage onto > > the Ethernet and locking up the entire network? > > I've not seen predictable results. Locking up both nodes is a very good > possibility though, as well as confusing the hell out of whatever host > they were both talking to. > > > > > What we want to do is provide single-user login from single MAC address, but > > we are worried about the possibility of someone punching down a connection > > and spoofing an address on the net. > > > > Rich Gautier > > I think you might want to look at another scheme:) > > ---------------------------------------------------------------------------- > It's *amazing* what one can accomplish when > one doesn't know what one can't do! > From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 10:15:50 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08747; Thu, 3 Nov 1994 07:00:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01705 Thu, 3 Nov 1994 06:58:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA01862; Thu, 3 Nov 1994 06:52:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA01857; Thu, 3 Nov 1994 06:51:56 +1100 Precedence: list Received: from access4.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04290; Thu, 3 Nov 1994 05:08:19 +1100 (from PAUL@tdr.com) Received: from smtpgate.TDR.COM by access4.digex.net with BSMTP id AA05359 (5.67b8/IDA-1.5 for ); Wed, 2 Nov 1994 13:07:16 -0500 Date: Wed, 02 Nov 1994 12:05:09 -0500 (EST) Message-Id: <01.1994Nov02.12h05m09s.PAUL@TDR.COM> To: ericf@atc.boeing.com, Big-Internet@munnari.OZ.AU Newsgroups: tdr.paul.private.mail Organization: Tansin A. Darcos & Company, Silver Spring, MD USA From: Paul Robinson Subject: Re: X.400 vs. SMTP Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- ericf@atc.boeing.com writes to Big-Internet@munnari.OZ.AU, as follows: > A thousand apologies for posting an issue to this list which > is inappropriate for the list. However, I am in a bit of a > quandry due to my own personal ignorance and am hoping that > several of you could rescue me. I'll say it's "debatable" whether it's "inappropriate". As I understand it, "big internet" deals with the expansion of the internet and handling size issues. X.400 is used on Internet, especially in Europe and there are several RFCs dealing with it. There is an X.400 list on Bitnet, also, which I can dig up if I can find it. We have to be prepared for heavier use of X.400 in the future since some places use it. > My problem is that we have some very strong X.400 advocates > who are making various claims about X.400 vis-a-vis SMTP. Mostly because X.400 services are proprietary in nature (=Exxtra Co$t) and it's pretty hard to charge much for an all-SMTP mail service when sendmail, as bad as it is, is free and so is the much less resource intensive SMail. > 1) X.400 is more reliable than SMTP both as a protocol and because it is > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. And it allows them to charge more money for it. That's not necessarily an indictment, it just shows the difference. Sites implement SMTP because they needed something simple and cheap, that works. Sites implement X.400 because they need something billable. Or because they needed specialized services (such as sending Facsimile) that isn't easily done via SMTP. (You can do it now by using mailbox format and having something trap mailboxes to the fax identifier, but it's probably harder to do using a sendmail service than it is to do it using, say, ISODE and PP, the most common non-proprietary X.400 programs, or were until they went commercial.) > 2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which > tremendously raises the security profile of X.400 far above all > competitors. They claim that PEM is not adequately secure to be > relied upon for business (commercial) communications. MCI Mail doesn't completely implement X.400 and does a piss-poor job on SMTP too. One of its error codes is a 600 series, which *isn't* defined by the SMTP RFC or any enhancements. And it bounces all addresses if one is bad. Just because a feature is out there doesn't mean they implement it. > 3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- > even with MIME. There are people working on defining a means of using SMTP to do EDI. The problems are related to the fact that with X.400 you (usually) transfer your messages via a third-party who transmits them to the recipient, thus ensuring nonrepudiation and nondeniability. With SMTP, the sender connects directly to the recipient and there is nobody else to have a copy of the transaction. Sendmail does support having a return receipt, it's an "undocumented feature" but in such a case you are depending on the recipient of a message - who may want to deny reception - verifying receipt of a message; there can be a conflict of interest. Another thing: have you priced EDI suppliers lately? Try $200 to set up an account, monthly recurring account charges and charges per message, say $1 each or so. SMTP collapses those transaction costs to *zero*. > 4) X.400's body parts are immensely flexible, able to carry > information of any content. MIME's body parts are almost equivalent > but it is not widely supported within SMTP products today. Not all of X.400 is supported by all vendors. Neither MCI Mail nor AT&T Mail, which I have used both, provide any kind of encryption or security features on messages. > 5) X.400 is a better Email backbone technology Since SMTP is usually from originator computer to destination computer, it's probably more reliable than the relay-based X.400. > 6) X.400 gives you receipt notification upon request while SMTP > does not. Sendmail and Smail SMTP implementations supports the header 'Receipt-Requested-by:' Smail might also support 'Delivery-Notification-To:' which sendmail does support. Delivery-Notification indicates when Sendmail got the message at the destination site; Receipt-Requested indicates when the user read it, if the user agent supports receipts. > 8) X.400 is widely used everywhere in the world except North > America. The best mailing list program in the world was written for SMTP technology. Listserv by Eric Thomas, of Swedish University. > 9) Virtually all Personal Computer Email systems have defined > X.400 to be their strategic direction towards which they will evolve > their product line. Thus, most proprietary Email systems will soon > natively use X.400 which means that it is the "Email system of the > future". I think I've seen better mailing capability in off-line mailers for BBS systems than in most of the PC-based "commercial" mail systems. They can't talk to competitor's programs without expensive gateways and headaches for administrators. > 10) The Electronic Messaging Association (EMA) has defined rich > calendaring and scheduling services -- and other "messaging" services -- > which rely upon X.400. You could still do the same thing with SMTP. Oh hell, I missed the whole point. SMTP is just a *transport mechanism* It consists of one site calling another, and delivering a message with some headers before the message, the basic set being HELO who.from MAIL FROM: RCPT TO: DATA Header1: information Header2: more information This is the text of the message. . QUIT In typical SMTP transfers, the material between DATA and . is an RFC-841 format message. *IT DOES NOT HAVE TO BE*. It could be an X.400 message! X.400 is two parts: a message descriptor and a transport mechanism. Internet separates that into SMTP (RFC 821 and enhancements) and the message format requirements (RFC 841 for standard flat text, and MIME (RFC 1521) for multimedia). A direct hit on your comments is in RFC 1506: J. Houttuin, "A tutorial on gatewaying between X.400 and Internet mail", 09/23/1993. The following notes might help: RFC 1495: H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson, "Mapping between X.400 and RFC-822 Message Bodies", 08/26/1993 RFC 1494: H. Alvestrand, S. Thompson, "Equivalences between 1988 X.400 and RFC-822 Message Bodies", 08/26/1993 RFC 1328: S. Hardcastle-Kille, "X.400 1988 to 1984 downgrading", 05/18/1992 RFC 1327: S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 and RFC 822", 05/18/1992 This last one runs over 100 pages and is very interesting if you like this sort of stuff. Steve Hardcastle-Kille has also written a book on X.400 services; I saw it once in a technical bookstore. All of the above can be retrieved from ds.internic.net:/rfc/rfcxxxx.txt where xxxx is the 4 digit number, e.g. 1327, 0822, 0821, etc. I can also recommend the following documents (since I wrote them) and they are also available at the above site, in ds.internic.net:/internet-drafts/x where x is the name of the draft, all drafts start with 'draft-'. The three I have done are: (Mail) ncftp>cd ../internet-drafts ds.internic.net:/internet-drafts (Mail) ncftp>dir draft-robinson* 37716 Aug 15 19:46 draft-robinson-bitmap-00.txt 119881 Aug 11 01:29 draft-robinson-mail-summary-00.txt 154714 Aug 11 01:30 draft-robinson-newtelex-00.txt The first one deals with transmitting MS-Windows icons and bitmaps via MIME; the second is a summary of every known text header used in mail and messages; the last includes a list of every X.400 provider I could find, and all the area codes and domain names in the world. --- Paul Robinson - Paul@TDR.COM Reports on Security Problems: To Subscribe write PROBLEMS-REQUEST@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: Ass, n.: The masculine of "lass". From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 12:28:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14800; Thu, 3 Nov 1994 09:54:05 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02025; Thu, 3 Nov 1994 09:52:48 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02020; Thu, 3 Nov 1994 09:43:58 +1100 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09867; Thu, 3 Nov 1994 07:41:55 +1100 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA09638; Wed, 2 Nov 1994 12:41:10 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 12:41:13 -0800 To: Paul Robinson From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: X.400 vs. SMTP Cc: ericf@atc.boeing.com, Big-Internet@munnari.OZ.AU At 9:05 AM 11/2/94, Paul Robinson wrote: >Or because they needed specialized services (such as sending Facsimile) >that isn't easily done via SMTP. (You can do it now by using mailbox If you look at the raw technical details, I doubt you'll find much difference. The reality is that this is something that is value-added by the sending and receiving UAs. It should have nothing to do with the underlying email transport service. >There are people working on defining a means of using SMTP to do EDI. >The problems are related to the fact that with X.400 you (usually) The gotcha in your statement is the 'usually'. The 'accountability' and 'logging' approach to non-repudiation is a matter of operational configuration. It has -- quite literally -- nothing to do with choice of technology. Hence, it does not show up any differences between X.400 and Internet mail. >recipient, thus ensuring nonrepudiation and nondeniability. With SMTP, >the sender connects directly to the recipient and there is nobody else to The same is possible (and done) for X.400. Going through a VAN is the same effort for both technologies. >Sendmail does support having a return receipt, it's an "undocumented >feature" but in such a case you are depending on the recipient of a >message - who may want to deny reception - verifying receipt of a >message; there can be a conflict of interest. Turns out, the same is true for X.400 delivery receipt. >say $1 each or so. SMTP collapses those transaction costs to *zero*. No it doesn't. It may collapse the per-transaction INCREMENTAL charge to zero, but attaching to the Internet and using it is not free. >Since SMTP is usually from originator computer to destination computer, >it's probably more reliable than the relay-based X.400. To repeat: BOTH technologies are relay-based. The required functions for an SMTP relay are fewer than for an X.400 relay. >The best mailing list program in the world was written for SMTP >technology. Listserv by Eric Thomas, of Swedish University. Gee. I thought that listserv was a bitnet (IBM mainframe) service, though there are now Internet-based clones of it. >In typical SMTP transfers, the material between DATA and . is an RFC-841 wow. haven't seen a reference to 841 in many years. But sorry, it's NOT what goes into the SMTP data section. RFC822 (with RFC1153 modifications) objects do. (And Mime, as appropriate.) In fact, the NBS FIPS spec that was published as RFC841 was strong input to the X.400 process. But it has nothing to do with Internet mail. It was published as a convenience to the Internet community, as is true for many other RFCs that are not standards. As to the possibility of puting X.400 objects into Data, that's been discussed. But I assumed that the current round of discussion had to do with the OSI email suite and the Internet email suite, rather than picking and choosing pieces from among them. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 14:13:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26546; Thu, 3 Nov 1994 14:13:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA02260; Thu, 3 Nov 1994 14:12:51 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA02244; Thu, 3 Nov 1994 13:58:51 +1100 Precedence: list Received: from sequoia.itd.uts.EDU.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25863; Thu, 3 Nov 1994 13:58:41 +1100 (from M.Gream@uts.EDU.AU) Received: from acacia.itd.uts.EDU.AU by sequoia.itd.uts.EDU.AU with SMTP id AA27499 (5.65c/IDA-1.4.4 for ); Thu, 3 Nov 1994 13:58:31 +1100 Received: by acacia.itd.uts.EDU.AU (4.1/SMI-4.1[gji]) id AA00426; Thu, 3 Nov 94 14:01:47 EST From: M.Gream@uts.edu.au (Matthew Gream) Message-Id: <9411030301.AA00426@acacia.itd.uts.EDU.AU> Subject: Re: Concerns about MAC spoofing (fwd) To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 3 Nov 94 14:01:47 EST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9411021540.1471@munnari.oz.au>; from "Darren Reed" at Nov 3, 94 02:38:14 am Organization: University of Technology, Sydney. X-Mailer: ELM [version 2.4dev PL17] "Darren Reed" wrote: > > For those who have been/were wondering about ethernet addresses being > unique, coming from the manufacturer and desiring to use the IEEE 802 > numbers as part of the EID, the following letter from the firewalls > mailing list should remove any doubt about how useful/useless this is. > > Unless PCs weren't being thought of at the time and/or not being desired > as part of IPng :-) What's your point ? For all intents and purposes, 802.3 MAC addresses _are_ unique except for when someone acts in an illicit manner. If it is intended to use the address to authenticate the machine (in a physical proximity), then the ability to change it's address causes a problem. But it's no more a problem that other physical security issues (insertion of a new machine), and solvable by filtering MAC bridges. If the intention is for the address to provide uniqueness to the EID, the under _normal_ operating conditions it is probably the best option available. Though it does assume that the underlying media is always of this type. Any subversion is only going to cause EID clashes. These would occur even more frequently if the EID uniqueness was determined by a `random number generator' rather than addresses. If the EID end points don't have MAC addresses (of a suitable form), then something `random' has to be generated anyway. A clash is still possible and there need to be strategies to deal with it. But since the occurance of such clashes is likely to be lower (still an assumption), a time-space tradeoff can be made. If I've misinterpreted your point, can you make it clearer ? Matthew. -- Matthew Gream (02) 821-2043 (sw/hw engineer) From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 16:09:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01050; Thu, 3 Nov 1994 15:55:57 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA02374; Thu, 3 Nov 1994 15:53:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA02369; Thu, 3 Nov 1994 15:41:34 +1100 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28789; Thu, 3 Nov 1994 15:07:39 +1100 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14761 Thu, 3 Nov 1994 15:07:36 +1100 (from kre@munnari.OZ.AU) To: M.Gream@uts.edu.au (Matthew Gream), avalon@coombs.anu.edu.au (Darren Reed) Cc: big-internet@munnari.OZ.AU Subject: Re: Concerns about MAC spoofing (fwd) In-Reply-To: Your message of "Thu, 03 Nov 1994 14:01:47 EST." <9411030301.AA00426@acacia.itd.uts.EDU.AU> Date: Thu, 03 Nov 1994 15:06:15 +1100 Message-Id: <11890.783835575@munnari.OZ.AU> From: Robert Elz There is no serious proposal to build EIDs out of MAC addresses in any way at all. If you're really considering EIDs here then this whole (short) conversation is a waste of time. On the other hand if you're talking about IPv6 addresses, or something, for which the (permitted) use of MAC addresses in automatic construction is certainly being considered, or I should say, more than considered, then you need to correct your terminology, or no-one is going to take any notice at all. kre From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 16:55:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03463; Thu, 3 Nov 1994 16:55:24 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA02441; Thu, 3 Nov 1994 16:52:52 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA02436; Thu, 3 Nov 1994 16:40:24 +1100 Precedence: list Received: from cheops.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02026; Thu, 3 Nov 1994 16:19:19 +1100 (from avalon@coombs.anu.edu.au) Message-Id: <9411030519.2026@munnari.oz.au> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA06444; Thu, 3 Nov 94 16:18:40 +1100 From: Darren Reed Subject: Re: Concerns about MAC spoofing (fwd) To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 3 Nov 1994 16:18:39 +1100 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <11890.783835575@munnari.OZ.AU> from "Robert Elz" at Nov 3, 94 03:06:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1168 > > There is no serious proposal to build EIDs out of MAC addresses > in any way at all. If you're really considering EIDs here > then this whole (short) conversation is a waste of time. > > On the other hand if you're talking about IPv6 addresses, or > something, for which the (permitted) use of MAC addresses in > automatic construction is certainly being considered, or I > should say, more than considered, then you need to correct > your terminology, or no-one is going to take any notice at all. > > kre Sorry, I just meant to highlight the dangers involved with using MAC addresses in any capacity for building a unique number on the premis that they're set by manufacturers and therefore `unchangable'; and given that an arguement against their use has been reluctance to trust that all cards have been made `different', I presumed this issue of being able to set some MAC addresses via software somewhat releveant. I'm aware that they're inappropriate for EIDs, being far too large and sparse in allocation. I can't say whether or not they would be of any use in IPv6 addresses, except that, once again, they maybe too big to be useful here. Darren From owner-Big-Internet@munnari.OZ.AU Thu Nov 3 21:55:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13883; Thu, 3 Nov 1994 21:55:30 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA02702; Thu, 3 Nov 1994 21:52:58 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA02697; Thu, 3 Nov 1994 21:49:32 +1100 Precedence: list From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13790; Thu, 3 Nov 1994 21:49:25 +1100 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 3 Nov 1994 02:49:17 -0800 Posted-Date: Thu, 3 Nov 1994 02:48:14 -0800 (PST) Message-Id: <199411031048.AA14632@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 3 Nov 1994 02:48:14 -0800 Subject: Re: Concerns about MAC spoofing (fwd) To: M.Gream@uts.edu.au (Matthew Gream) Date: Thu, 3 Nov 1994 02:48:14 -0800 (PST) Cc: avalon@coombs.anu.edu.au, big-internet@munnari.OZ.AU In-Reply-To: <9411030301.AA00426@acacia.itd.uts.EDU.AU> from "Matthew Gream" at Nov 3, 94 02:01:47 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 809 > What's your point ? > > For all intents and purposes, 802.3 MAC addresses _are_ unique except > for when someone acts in an illicit manner. This is wrong. Locally administered MAC addresses are part of the ethernet spec from the Xerox Grey book. My implementation of a valid spec does not constitute "illicit" behaviour. > If the intention is for the address to provide uniqueness to the EID, > the under _normal_ operating conditions it is probably the best option > available. Media issues aside, the point is that a better understanding of and method for generating globally unique EIDs is desired. Reuse of MAC addresses where available does not meet the acceptance criteria (well mine anyway) due to the caveat of local administration of MAC addresses being a valid use/implementation. --bill From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 06:41:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26900; Fri, 4 Nov 1994 04:13:25 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03093; Fri, 4 Nov 1994 04:13:00 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03088; Fri, 4 Nov 1994 04:10:32 +1100 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26709; Fri, 4 Nov 1994 04:10:25 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14016; Thu, 3 Nov 94 12:09:56 -0500 Date: Thu, 3 Nov 94 12:09:56 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9411031709.AA14016@ginger.lcs.mit.edu> To: M.Gream@uts.edu.au, bmanning@isi.edu Subject: Re: Concerns about MAC spoofing (fwd) Cc: avalon@coombs.anu.edu.au, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: bmanning@isi.edu Locally administered MAC addresses are part of the ethernet spec from the Xerox Grey book. My implementation of a valid spec does not constitute "illicit" behaviour. ... Reuse of MAC addresses where available does not meet the acceptance criteria ... due to the caveat of local administration of MAC addresses being a valid use/implementation. So? Add the sentence "Locally administered MAC-addresses MUST NOT be used to form EID's, in that portion of the EID-space in which EID's are formed by mapping IEEE numbers." Or, better yet, save the space: don't allocate the portion of the EID space that would contain locally-administered MAC addresses; i.e. the chunk of the EID space that you allocate to EID's is less than 2^48. Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 08:22:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02648; Fri, 4 Nov 1994 06:55:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03249; Fri, 4 Nov 1994 06:53:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03246; Fri, 4 Nov 1994 06:48:53 +1100 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29350; Fri, 4 Nov 1994 05:29:47 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14502; Thu, 3 Nov 94 13:29:43 -0500 Date: Thu, 3 Nov 94 13:29:43 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9411031829.AA14502@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bmanning@isi.edu Subject: Re: Concerns about MAC spoofing (fwd) Cc: jnc@ginger.lcs.mit.edu From: bmanning@isi.edu So, I can use the existing facility to map as a locally administered address to what YOU think of as globally unique, burned in MAC addresses. How can you tell? You can't. Sorry, but I'm not familiar with the mapping mechanism you allude to. Just placing that kind of verbage in a spec opens it up to all kinds of security holes. As to the security, as I said in a reply to Darren which hasn't made it though the list yet, use of any single identifying number such as an address or endpoint name is not secure, and cannot be made secure. Use of IEEE numbers was not intended to provide security, simply a convenient source of probably globallyy unique numbers. If you want security, you have to add the real thing. Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:11:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02697; Fri, 4 Nov 1994 06:58:30 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03277; Fri, 4 Nov 1994 06:58:20 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03223; Fri, 4 Nov 1994 06:38:39 +1100 Precedence: list From: bmanning@isi.edu Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26999; Fri, 4 Nov 1994 04:16:49 +1100 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 3 Nov 1994 09:16:40 -0800 Posted-Date: Thu, 3 Nov 1994 09:15:39 -0800 (PST) Message-Id: <199411031715.AA15624@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 3 Nov 1994 09:15:39 -0800 Subject: Re: Concerns about MAC spoofing (fwd) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Nov 1994 09:15:39 -0800 (PST) Cc: M.Gream@uts.edu.au, bmanning@isi.edu, avalon@coombs.anu.edu.au, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9411031709.AA14016@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 3, 94 12:09:56 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1133 > > From: bmanning@isi.edu > > Locally administered MAC addresses are part of the ethernet spec from the > Xerox Grey book. My implementation of a valid spec does not constitute > "illicit" behaviour. ... Reuse of MAC addresses where available does not > meet the acceptance criteria ... due to the caveat of local > administration of MAC addresses being a valid use/implementation. > > So? Add the sentence "Locally administered MAC-addresses MUST NOT be used to > form EID's, in that portion of the EID-space in which EID's are formed by > mapping IEEE numbers." Or, better yet, save the space: don't allocate the > portion of the EID space that would contain locally-administered MAC > addresses; i.e. the chunk of the EID space that you allocate to EID's is less > than 2^48. > So, I can use the existing facility to map as a locally administered address to what YOU think of as globally unique, burned in MAC addresses. How can you tell? You can't. Just placing that kind of verbage in a spec opens it up to all kinds of security holes. again... not what I would do... but feel free. --bill From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:11:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02724; Fri, 4 Nov 1994 07:00:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03296; Fri, 4 Nov 1994 06:59:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03243; Fri, 4 Nov 1994 06:47:39 +1100 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28674; Fri, 4 Nov 1994 05:06:33 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14344; Thu, 3 Nov 94 13:06:22 -0500 Date: Thu, 3 Nov 94 13:06:22 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9411031806.AA14344@ginger.lcs.mit.edu> To: avalon@coombs.anu.edu.au, jnc@ginger.lcs.mit.edu Subject: Re: Concerns about MAC spoofing (fwd) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Darren Reed Out of interest, is the handling of duplicate EIDs being catered for, or will it just be a case of having to reconfigure ? It is quite likely it is already covered, I've seen a large amount of mail arrive on ipng which I haven't caught up with yet... I don't think there is any consensus on even having endpoint names (be they EID's, or anything else, such as DNS names) as a formal part of the architecture. As such, there hasn't been any call to finalize all the details of how they work, including such topics as what to do about collisions, although there has been some discussion of it (e.g. if all endpoint names are in a distributed directory, you discover collisions when you try and add your new one, which conflicts with an existing one). in the case of the 64bit EID, using all of the MAC locally (48bit version) it only leaves 16bits for some sort of topology/providor/etc. Arrgghh! One main point of separating endpoint names (such as EID's) from addresses is that endpoint names *do not* contain any topology information! There's *no* information in the remaining 16 bits; it's just a random number that says "IEEE segment of EID space". Also, whilst I'm thinking about this, how would other sized MACs be handled? There a spec. for 802 addresses being 60 and 16 bit long as well as 48? IEEE numbers were used as a conventient source of (allegedly) globally unique numbers; i.e. it was purely a conveniene thing. There's no need to support all MAC addresses for this purpose unless the convenience factor is high enough. If there are enough uses of 60-bit MAC's, they could be supported too. The 16-bit ones are not directly useful, as they are not globally unique. Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:12:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02743; Fri, 4 Nov 1994 07:01:10 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03313; Fri, 4 Nov 1994 07:01:00 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03237; Fri, 4 Nov 1994 06:42:31 +1100 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26545; Fri, 4 Nov 1994 04:04:32 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13977; Thu, 3 Nov 94 12:04:14 -0500 Date: Thu, 3 Nov 94 12:04:14 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9411031704.AA13977@ginger.lcs.mit.edu> To: avalon@coombs.anu.edu.au, kre@munnari.OZ.AU Subject: Re: Concerns about MAC spoofing (fwd) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Darren Reed the dangers involved with using MAC addresses in any capacity for building a unique number on the premis that they're set by manufacturers and therefore `unchangable' ... I presumed this issue of being able to set some MAC addresses via software somewhat releveant. I don't see why. Anyone who uses any single number (be it an address, or an endpoint name such as an EID) to authenticate a transaction is crazy. It's just way too easy to spoof, and it doesn't matter where it comes from; off a card, from an assignment authority, etc. (Addresses differ from endpoint names such as EID's only in limiting the topological scope over which spoofing can occur - as long as you disallow source routes - but other than that, on their own, they aren't any more secure, really.) If you really care about security, you have to have some sort of authentication, and you need to get keys securely (which usually involves an out-of-band transfer *somewhere*, even if it's typing the public key of a centralized KDC). Use of IEEE numbers was suggested as a source of EID's for two reasons: first, they provide a easy source of fairly reliably unique numbers (and obviously, if your software doesn't use the value from the ROM on the card, but picks one, this doesn't apply), and second, since they are built into the machine, they make auto-configuration easier. Nothing was ever said about them being secure, on their own. They're not, and it should be blindingly obvious that they are not. I'm aware that they're inappropriate for EIDs, being far too large and sparse in allocation. Really? I've never heard a single proposal for EID's that had them be less than 48 bits. If you want something globally unique, it almost has to be that many bits or more. How long did you think an EID was? Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:12:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02770; Fri, 4 Nov 1994 07:02:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03331; Fri, 4 Nov 1994 07:02:16 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03240; Fri, 4 Nov 1994 06:46:47 +1100 Precedence: list Received: from cheops.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27956; Fri, 4 Nov 1994 04:40:33 +1100 (from avalon@coombs.anu.edu.au) Message-Id: <9411031740.27956@munnari.oz.au> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA15689; Fri, 4 Nov 94 04:39:46 +1100 From: Darren Reed Subject: Re: Concerns about MAC spoofing (fwd) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 4 Nov 1994 04:39:46 +1100 (EDT) Cc: avalon@coombs.anu.edu.au, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU In-Reply-To: <9411031704.AA13977@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 3, 94 12:04:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1923 [...] >Use of IEEE numbers was suggested as a source of EID's for two reasons: first, > they provide a easy source of fairly reliably unique numbers (and obviously, > if your software doesn't use the value from the ROM on the card, but picks > one, this doesn't apply), and second, since they are built into the machine, > they make auto-configuration easier. Nothing was ever said about them being > secure, on their own. They're not, and it should be blindingly obvious that > they are not. Yes, I think it was rather stupid of me to (re)introduce this topic. I won't be making the mistake (or at least trying not to) of either being ambiguous about EIDs/addresses again. Out of interest, is the handling of duplicate EIDs being catered for, or will it just be a case of having to reconfigure ? It is quite likely it is already covered, I've seen a large amount of mail arrive on ipng which I haven't caught up with yet... > I'm aware that they're inappropriate for EIDs, being far too large and > sparse in allocation. > > Really? I've never heard a single proposal for EID's that had them be less > than 48 bits. If you want something globally unique, it almost has to be that > many bits or more. How long did you think an EID was? You seem to have misunderstood what I meant, although I wasn't very clear at all, either, sorry. As was pointed out recently, in the case of the 64bit EID, using all of the MAC locally (48bit version) it only leaves 16bits for some sort of topology/providor/etc. I meant they were too big to be used in conjunction with other bits and still fit in a compact space. Also, whilst I'm thinking about this, how would other sized MACs be handled ? There a spec. for 802 addresses being 60 and 16 bit long as well as 48 ? (Came across the possibility of 60 bit MAC addresses whilst reading about DQDB and the IMPDU header which uses 8 bytes to store MAC addresses). Darren From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:12:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03022; Fri, 4 Nov 1994 07:15:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA03360; Fri, 4 Nov 1994 07:13:09 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA03324; Fri, 4 Nov 1994 07:01:50 +1100 Precedence: list From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29738; Fri, 4 Nov 1994 05:40:52 +1100 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 3 Nov 1994 10:40:47 -0800 Posted-Date: Thu, 3 Nov 1994 10:39:46 -0800 (PST) Message-Id: <199411031839.AA15755@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Thu, 3 Nov 1994 10:39:46 -0800 Subject: Re: Concerns about MAC spoofing (fwd) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Nov 1994 10:39:46 -0800 (PST) Cc: big-internet@munnari.OZ.AU, bmanning@ISI.EDU, jnc@ginger.lcs.mit.edu In-Reply-To: <9411031829.AA14502@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 3, 94 01:29:43 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1577 > > From: bmanning@isi.edu > > So, I can use the existing facility to map as a locally administered > address to what YOU think of as globally unique, burned in MAC addresses. > How can you tell? You can't. > > Sorry, but I'm not familiar with the mapping mechanism you allude to. The ability to change the factory provided address to a locally administered address on any ethernet controller. For my sun, it's changing the address family from inet (default) to ether. I can give my Sun the same address as the 3C501 in my lowly 286 PC. I can also change my cisco ethernet MAC address to the same thing. Voila.. It now looks like the same 3com registered MAC address on my wire. > > Just placing that kind of verbage in a spec opens it up to all kinds of > security holes. > > As to the security, as I said in a reply to Darren which hasn't made it though > the list yet, use of any single identifying number such as an address or > endpoint name is not secure, and cannot be made secure. Use of IEEE numbers > was not intended to provide security, simply a convenient source of probably > globallyy unique numbers. If you want security, you have to add the real > thing. I simply point out that the use of this convenient source of probably globally unique numbers WILL engender a false sense of security by those who will think they can be enforced as globally unique numbers. For the bad-hats in the neighborhood, this is an invite to exploite. This is one that clearly belongs in the "Security Not covered in this Memo" section. --bill From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:26:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04889; Fri, 4 Nov 1994 08:15:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA03429; Fri, 4 Nov 1994 08:13:06 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA03424; Fri, 4 Nov 1994 08:12:50 +1100 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02213; Fri, 4 Nov 1994 06:42:37 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15129; Thu, 3 Nov 94 14:42:32 -0500 Date: Thu, 3 Nov 94 14:42:32 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9411031942.AA15129@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bmanning@isi.edu Subject: Re: Concerns about MAC spoofing (fwd) Cc: jnc@ginger.lcs.mit.edu From: bmanning@isi.edu >> So, I can use the existing facility to map as a locally administered >> address to what YOU think of as globally unique, burned in MAC >> addresses. How can you tell? You can't. > Sorry, but I'm not familiar with the mapping mechanism you allude to. The ability to change the factory provided address to a locally administered address on any ethernet controller. This is just the ability to change Ethernet addresses Darren's original message mentioned. (If the new address is a locally administered - i.e. not globally-unique - one, it's not suitable for use as a globally-unique endpoint name anyway, but that's orthagonal to the problems raised by being able to change them.) I simply point out that the use of this convenient source of probably globally unique numbers WILL engender a false sense of security by those who will think they can be enforced as globally unique numbers. ... This is one that clearly belongs in the "Security Not covered in this Memo" section. Yup! No disagreement there. One hopeful sign I will note is that as time passes, more and more people are becoming more knowledgeable about security issues, so that whole problem of false security from globally unique numbers is one that hopefully will fade. Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 4 09:58:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07335; Fri, 4 Nov 1994 09:17:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03498; Fri, 4 Nov 1994 09:13:06 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03493; Fri, 4 Nov 1994 09:11:17 +1100 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01943; Fri, 4 Nov 1994 06:37:46 +1100 (from vjs@rhyolite.denver.sgi.com) Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id LAA20582; Thu, 3 Nov 1994 11:37:36 -0800 Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA16295; Thu, 3 Nov 94 12:37:00 -0700 Date: Thu, 3 Nov 94 12:37:00 -0700 From: vjs@rhyolite.denver.sgi.com (Vernon Schryver) Message-Id: <9411031937.AA16295@rhyolite.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: Concerns about MAC spoofing (fwd) >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > From: bmanning@isi.edu > > Locally administered MAC addresses are part of the ethernet spec from the > Xerox Grey book. My implementation of a valid spec does not constitute > "illicit" behaviour. ... Reuse of MAC addresses where available does not > meet the acceptance criteria ... due to the caveat of local > administration of MAC addresses being a valid use/implementation. > >So? Add the sentence "Locally administered MAC-addresses MUST NOT be used to >form EID's, in that portion of the EID-space in which EID's are formed by >mapping IEEE numbers." Or, better yet, save the space: don't allocate the >portion of the EID space that would contain locally-administered MAC >addresses; i.e. the chunk of the EID space that you allocate to EID's is less >than 2^48. Once upon a time, I thought that no reasonable vendors ever shipped any hardware that reused IEEE addresses. I have since learned that there are only two classes of vendors: 1. those that have never dupicated the use of globally administrated addresses, but have only shipped a few devices (e.g. only 1000's of systems). 2. those that have shipped more than one device using the same IEEE address. All large vendors are in class 2 because - mistakes in manufacturing are inevitiable, sooner or later. If you buy PROMs guaranteed to contain different numbers, sooner or later the maker of PROMs will make a mistake and give you a duplicate batch and you will ship a lot of them. If you have some automatic or semi-automatic machinery that installs MAC addresses on the manufacturing floor, sooner or later someone will decide to rewind or rest the automatic machinery for some superficially good reason, you'll ship a run of duplicates. - things happen in the field. There is enormous pressure from customers to keep their old Ethernet address when systems are fixed, or boards swapped. That causes field service organizations to find and use the mechanisms used by the manufacturing organization to set the IEEE address. Mistakes are inevitiable, but most of them are benign and never detected. With most of those mistakes, you won't discover that Ethernet addresses have been duplicated until a lot of duplicates are in customer hands. Duplicate addresses cause not problems and are practically undetectable unless the dopplegangers are on the same LAN. You can ever fix or recall all of the duplicates. In fact, you will never find or hear about all of the duplicates. It will not be until and unless something like having IPv6 rely on the genuinely global uniqueness of IEEE addresses will you hear about most of your duplicate IEEE addresses. Whether the inevitable problems from assuming that all globally administrated IEEE addresses are unique are too great is a matter of judgement. If you do use IEEE addresses, you better have good enough mechanisms to diagnose the inevitiable problems. To put this fact of life another way, don't bet anyone's life on two people having different social security numbers. (I assume everyone has heard of the people with duplicate social security numbers.) Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Mon Nov 7 01:12:58 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10381; Mon, 7 Nov 1994 00:27:57 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08176 Mon, 7 Nov 1994 00:17:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA06731; Mon, 7 Nov 1994 00:14:14 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06726; Mon, 7 Nov 1994 00:12:10 +1100 Precedence: list Received: from [131.112.32.132] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09848; Mon, 7 Nov 1994 00:11:54 +1100 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 6 Nov 94 22:00:49 +0859 From: Masataka Ohta Message-Id: <9411061301.AA03013@necom830.cc.titech.ac.jp> Subject: Re: Concerns about MAC spoofing (fwd) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sun, 6 Nov 94 22:00:48 JST Cc: big-internet@munnari.OZ.AU, bmanning@isi.edu, jnc@ginger.lcs.mit.edu In-Reply-To: <9411031829.AA14502@ginger.lcs.mit.edu>; from "Noel Chiappa" at Nov 3, 94 1:29 pm X-Mailer: ELM [version 2.3 PL11] > As to the security, as I said in a reply to Darren which hasn't made it though > the list yet, use of any single identifying number such as an address or > endpoint name is not secure, and cannot be made secure. Use of IEEE numbers > was not intended to provide security, simply a convenient source of probably I think everyone now agrees that EID should be used for database lookup. If security is desired, looking up of public keys is also the intended use of EID. If the database is secure DNS to access public key, EID hierarchy should be related to administration (not routing) hierarchy of end-users, not manifacturers hierarchy. Since, embedding MAC in EID is a bad idea. Q.E.D. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Nov 8 21:25:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07457; Tue, 8 Nov 1994 19:02:43 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA08908; Tue, 8 Nov 1994 18:55:01 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA08903; Tue, 8 Nov 1994 18:49:50 +1100 Precedence: list Received: from leonis.nus.sg by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05063; Tue, 8 Nov 1994 17:57:39 +1100 (from engp4048@leonis.nus.sg) Received: (from engp4048@localhost) by leonis.nus.sg (8.6.9/8.6.9/CNS-3.5) id OAA27181; Tue, 8 Nov 1994 14:55:50 +0800 Date: Tue, 8 Nov 1994 14:55:49 +0800 (SST) From: Shen Gang To: big-internet Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I am a postgraduate student of NUS majorred in communication. I wonder what kind of information I can get from this email address. Is there anyone wants to help me, please? Regards Shengang From owner-Big-Internet@munnari.OZ.AU Sat Nov 26 21:15:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02894; Sat, 26 Nov 1994 18:10:04 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA00811; Sat, 26 Nov 1994 18:04:21 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA00804; Sat, 26 Nov 1994 17:57:22 +1100 Precedence: list Received: from ietf.cnri.reston.va.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04637; Thu, 24 Nov 1994 07:08:07 +1100 (from cclark@CNRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05072; 23 Nov 94 10:59 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: end2end-interest@isi.edu, Big-Internet@munnari.OZ.AU From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-huitema-multi-homed-00.txt Date: Wed, 23 Nov 94 10:59:03 -0500 Sender: cclark@CNRI.Reston.VA.US Message-Id: <9411231059.aa05072@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-homed TCP Author(s) : C. Huitema Filename : draft-huitema-multi-homed-00.txt Pages : 17 Date : 11/22/1994 Current TCP connections are identified by pairs of host addresses and port numbers. This introduces a "fate sharing" dependency between the connection and these values, and specially with the time to live of the host addresses. Internet-Drafts are 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-huitema-multi-homed-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-huitema-multi-homed-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-huitema-multi-homed-00.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19941122155700.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-huitema-multi-homed-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huitema-multi-homed-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941122155700.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--