From daemon Wed Nov 5 00:22:37 1997 Delivery-Date: Wed, 05 Nov 1997 00:26:11 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id AAA23230 for ietf-outbound.10@ietf.org; Wed, 5 Nov 1997 00:22:19 -0500 (EST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA23216 for ; Wed, 5 Nov 1997 00:22:16 -0500 (EST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPMGFIHCK09JEXJ2@INNOSOFT.COM> for ietf@ietf.org; Tue, 4 Nov 1997 21:21:45 PST Date: Tue, 04 Nov 1997 21:14:15 -0800 (PST) From: Ned Freed Subject: RE: I-D ACTION:draft-hoffman-smtp-ssl-04.txt In-reply-to: "Your message dated Tue, 04 Nov 1997 23:01:11 -0500 (EST)" To: Chris Rapier Cc: "ietf@ietf.org" Message-id: <01IPMK117LJY9JEXJ2@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <01BCE955.BE5D2A80@ppp-hg1-29.ftwotx.onramp.net> > I happen to think that there is a lot of leeway within the SMTP > architecture that we aren't taking advantage of. > For example... > Can we assume that most SMTP handlers will respond with an error on an > unknown command and then continue? If we can assumee that then we have a > reasonable way of determining if an MTA can support additional hooks. > Between compatible MTAs one of thse hooks could be establishment of a > secure connection prior to the passage of envelope information. If the > recipient doesn't support SSL or TSL or whatever, the sender will > fallback to cleartext. Such assumptions are unnecessary. The standard SMTP protocol now supports an EHLO command. (See RFC 1869 for details, and note that this is now a full Internet Standard.) This command list the extensions which are available. If a given extension like, say, TLS, is listed as available, one can assume that the commands associated with TLS are also available. Paul's SSL draft already uses this facility to advantage. Ned From fred@cisco.com Mon Feb 2 16:20:11 1998 Delivery-Date: Mon, 02 Feb 1998 16:20:12 -0500 Return-Path: fred@cisco.com Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA05604 for ; Mon, 2 Feb 1998 16:20:11 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04273 for ; Mon, 2 Feb 1998 16:22:54 -0500 (EST) Received: from airedale.cisco.com (airedale.cisco.com [171.69.1.135]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id QAA05412; Mon, 2 Feb 1998 16:12:10 -0500 (EST) Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by airedale.cisco.com (8.6.12/8.6.5) with ESMTP id NAA24085; Mon, 2 Feb 1998 13:09:13 -0800 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199802022046.PAA09243@jekyll.piermont.com> References: Your message of "Mon, 02 Feb 1998 11:06:05 PST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Feb 1998 13:08:50 -0800 To: perry@piermont.com From: Fred Baker Subject: Re: could you please give me some advice? Cc: wgchairs@ns.ietf.org, bofchairs@ns.ietf.org At 3:46 PM -0500 2/2/98, Perry E. Metzger wrote: >Failing that, though, putting the plenary on Friday morning will >likely result in little to no attendance at the plenary. so you're suggesting Friday *evening* over Friday *morning*, and if we actually want anyone to attend it, not do it Friday at all. Close? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The greatest danger in times of turbulence is not the turbulence. It is to act with yesterday's logic." ---Peter Drucker From owner-nat@livingston.com Wed Feb 4 18:49:11 1998 Delivery-Date: Wed, 04 Feb 1998 18:49:16 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA23957 for ; Wed, 4 Feb 1998 18:49:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA08184; Wed, 4 Feb 1998 15:36:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA19089 for nat-outgoing; Wed, 4 Feb 1998 15:41:04 -0800 (PST) Message-ID: <5CEA8663F24DD111A96100805FFE658701FDE818@red-msg-51.dns.microsoft.com> From: Vinod Valloppillil To: "'Perry E. Metzger'" , Dan Nessett Cc: ipsec@tis.com, nat@livingston.com Subject: RE: (NAT) Re: Interactions between IPSEC and NAT Date: Wed, 4 Feb 1998 15:26:10 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Vinod Valloppillil that's a pretty large overstatement, IMHO. fundamentals of IPSEC/NAT aside, it doesn't seem theoretically impossible to separate IP addressing from end-to-end payload security. HTTPS through a NAT, for example, is perfectly reasonable and I believe works almost all the time (only breakage to be found is the handful of sites out there that embed IP addrs in cookies) > -----Original Message----- > From: Perry E. Metzger [SMTP:perry@piermont.com] > Sent: Wednesday, February 04, 1998 1:00 PM > To: Dan Nessett > Cc: ipsec@tis.com; nat@livingston.com > Subject: (NAT) Re: Interactions between IPSEC and NAT > > > Dan Nessett writes: > > Anyone thought about this so that they can provide us with a nice clean > > answer :-) ? > > Yes. If you want security, you can't use NAT, because by definition > the thing NAT is trying to do (peek in and/or alter your packets) is > what security is designed to prevent. Protocols like SSL have exactly > the same issue, btw. Any protocol that protects the contents of your > data will have the same issue. > > This is not fixable -- any "fixes" someone could propose to this would > be so horrible as to make the entire point of security moot. > > Perry > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 4 19:33:40 1998 Delivery-Date: Wed, 04 Feb 1998 19:33:40 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA24655 for ; Wed, 4 Feb 1998 19:33:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA09899; Wed, 4 Feb 1998 16:20:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA23332 for nat-outgoing; Wed, 4 Feb 1998 16:25:32 -0800 (PST) Message-ID: <5CEA8663F24DD111A96100805FFE658701FDE81E@red-msg-51.dns.microsoft.com> From: Vinod Valloppillil To: "'perry@piermont.com'" Cc: ipsec@tis.com, nat@livingston.com Subject: RE: (NAT) Re: Interactions between IPSEC and NAT Date: Wed, 4 Feb 1998 16:25:03 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Vinod Valloppillil >> HTTPS through a NAT, for example, is perfectly reasonable >HTTPS doesn't embed things like ports into the communications stream, >so it can be NATed. SSL is the security layer HTTPS uses, but SSL != >HTTPS -- other protocols over SSL will not behave so nicely. But my example of HTTPS through NAT is a case where you both both NAT features and end-to-end security. My point was to demonstrate the independance of IP addr/ports from end-end security. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 4 19:59:51 1998 Delivery-Date: Wed, 04 Feb 1998 19:59:52 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id TAA25382 for ; Wed, 4 Feb 1998 19:59:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA11260; Wed, 4 Feb 1998 16:46:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA25519 for nat-outgoing; Wed, 4 Feb 1998 16:51:01 -0800 (PST) Message-Id: <199802050050.TAA27730@jekyll.piermont.com> To: Vinod Valloppillil cc: "'perry@piermont.com'" , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 16:25:03 PST." <5CEA8663F24DD111A96100805FFE658701FDE81E@red-msg-51.dns.microsoft.com> X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Feb 1998 19:50:05 -0500 From: "Perry E. Metzger" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Perry E. Metzger" Vinod Valloppillil writes: > > >> HTTPS through a NAT, for example, is perfectly reasonable > > >HTTPS doesn't embed things like ports into the communications stream, > >so it can be NATed. SSL is the security layer HTTPS uses, but SSL != > >HTTPS -- other protocols over SSL will not behave so nicely. > > But my example of HTTPS through NAT is a case where you both both NAT > features and end-to-end security. My point was to demonstrate the > independance of IP addr/ports from end-end security. You've demonstrated nothing of the sort. All you've shown is that there exists a particular protocol that does okay that way. Unless you are proposing that the only application for the internet is web service over HTTPS, I'm afraid you'll have to accept that some protocols do not and cannot play well with both NAT and end to end security. Perry - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 4 22:08:50 1998 Delivery-Date: Wed, 04 Feb 1998 22:08:50 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA26104 for ; Wed, 4 Feb 1998 22:08:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA16257; Wed, 4 Feb 1998 19:00:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA04865 for nat-outgoing; Wed, 4 Feb 1998 19:05:38 -0800 (PST) Message-Id: <199802050302.WAA27045@postal.research.att.com> To: Vinod Valloppillil cc: "'perry@piermont.com'" , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Wed, 04 Feb 1998 22:02:33 -0500 From: Steve Bellovin Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Steve Bellovin >> HTTPS through a NAT, for example, is perfectly reasonable >HTTPS doesn't embed things like ports into the communications stream, >so it can be NATed. SSL is the security layer HTTPS uses, but SSL != >HTTPS -- other protocols over SSL will not behave so nicely. But my example of HTTPS through NAT is a case where you both both NAT features and end-to-end security. My point was to demonstrate the independance of IP addr/ports from end-end security. As always, there are tradeoffs. Every form of encryption has its own advantages and disadvantages. Some forms play more nicely with NAT than do others; by the same token, they have their own peculiar limitations. IPsec operates below the transport layer. This means that it protects the entire transport packet -- for TCP or UDP -- including the header. As noted by others, that provides protection against SYN flooding, spurious RST packets, and a host of other ills. Among the interesting fields protected is the transport checksum -- which, in the case of TCP and UDP, would include the pseudo-header. And that, of course, has the source and destination IP addresses. This is a fundamental incompatibility with NAT -- you can't diddle *any* IPsec-protected packet, even if the protocol in question doesn't contain embedded IP addresses. On the other hand, IPsec generally requires kernel-level changes; an application can't implement it for itself on most systems. That's why Netscape introduced SSL -- it was something that an application could do, without modification to the operating system. SSL operates above TCP. This means that you can pass it through a NAT gateway for protocols that don't use embedded IP addresses. The Web is usually clean, though some sites are foolish enough to use IP addresses in URLs or cookies. A more serious drawback to SSL is that in general, one does have to touch every application. While one could conceivably tinker with the libraries -- say, a funky DLL on Windows, or a shared library on UNIX systems -- most protocols don't know how to decline SSL if they weren't designed for such things. Even if they were -- telnet comes to mind -- the negotiation is inherently protocol-specific; a hack that might work for SMTP (say, via ELHO) wouldn't work for NNTP. Web browsers don't even try negotiating at this level, for the obvious reason that it's too messy -- they just use a different port number. And there's no fallback (at least, not in any browser I've seen) -- if no one is hope on port 443, the connection attempt simply fails. Which is better, IPsec or SSL? I don't know; which is better, blue or red? Oranges or apples? Compact or tasty? As always, it's wise to look at our middle name: "engineering". There are tradeoffs; what's best for one situation is not best for another. In general, I like IPsec better, especially because it's so well-suited to gateway-to-gateway or host-to-gateway encryption. That let's a site make its own tradeoffs between economy of deployment and granularity of protection. But there's no doubt that SSL (and ssh, which operates at a similar layer) are protecting far more sessions (and probably bytes) in today's Internet, because they're easier to deploy. Furthermore, they provide even finer-grained protection -- to the level of the individual user. IPsec is supposed to be able to do that, but it's relatively hard to do. I strongly doubt that there are any magic NAT fixes that can make it play more nicely with IPsec. The purpose of NAT is to make unpleasant (but hopefully useful) changes to packets; however, a design goal of IPsec was to prevent any changes, pleasant or not, useful or not. If you must have both, you'll probably have to do both on the same box, in an integrated fashion. That may mean the end systems, of course. (As a teaser, that's not a ridiculous statement. In fact, there are characteristics of IPsec that make co-resident NAT work quite nicely. In my copious free time, I'm trying draft an RFC entitled "IPsec, EIDs, and HostNAT", where EID is "endpoint identifier".) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Feb 4 22:45:44 1998 Delivery-Date: Wed, 04 Feb 1998 22:45:44 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id WAA28034 for ; Wed, 4 Feb 1998 22:45:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA18043; Wed, 4 Feb 1998 19:37:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA07608 for nat-outgoing; Wed, 4 Feb 1998 19:42:57 -0800 (PST) Message-Id: <3.0.3.32.19980204194615.0090c100@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 04 Feb 1998 19:46:15 -0800 To: perry@piermont.com, Dan Nessett From: Alex Alten Subject: (NAT) Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802042059.PAA23774@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Alex Alten At 03:59 PM 2/4/98 -0500, Perry E. Metzger wrote: > >Dan Nessett writes: >> Anyone thought about this so that they can provide us with a nice clean >> answer :-) ? > >Yes. If you want security, you can't use NAT, because by definition >the thing NAT is trying to do (peek in and/or alter your packets) is >what security is designed to prevent. Protocols like SSL have exactly >the same issue, btw. Any protocol that protects the contents of your >data will have the same issue. > >This is not fixable -- any "fixes" someone could propose to this would >be so horrible as to make the entire point of security moot. > >Perry > > This is what bothers me about the direction IPSEC has taken. The addition of security should not break things like trusted NATs. If you define an IP "trusted node" as all hosts, routers, firewalls, NATs, etc., that want to interoperate securely as a secure network. Then the only thing IPSEC should do is secure IP packets, the IP header and payload, between two trusted nodes (actually between two trusted interfaces). The question that remains is whether or not to allow untrustworthy nodes to handle the IP packets. If not, then encrypt the IP header, since all the trusted routers can decrypt it, decide how to route it, and then re-encrypt before transmitting it. If so, then just MAC the IP header (but still encrypt & MAC the payload). In this latter case insecure NATs (and routers which fragment) will not be able to work with the secure nodes, but any insecure node that doesn't adjust the IP packet will work as-is. The really difficult issues of how to establish and control the network of trusted nodes, and how to implement and enforce network-wide policy can then be tackled. - Alex Alex Alten Andrade@Andrade.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 00:04:07 1998 Delivery-Date: Thu, 05 Feb 1998 00:04:08 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA03886 for ; Thu, 5 Feb 1998 00:04:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA22737; Wed, 4 Feb 1998 20:52:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA12726 for nat-outgoing; Wed, 4 Feb 1998 20:57:20 -0800 (PST) From: Cheng_Chen@3com.com X-Lotus-FromDomain: 3COM To: "Perry E. Metzger" cc: Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Message-ID: <852565A1.0082AA92.00@hqoutbound.ops.3com.com> Date: Wed, 4 Feb 1998 18:55:07 -0500 Subject: (NAT) Re: Interactions between IPSEC and NAT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Cheng_Chen@3com.com We all lock our house every morning when we go to work, although we know that any average thief will be able to break it. So many of us pay $3000 to install the home security system, although we know that any average thief will cut your power line to disable the security system before they enter the house. NAT is valuable to many people. As a NAT user, a less than perfect security is better than NO security at all. Don't you lock your front door every morning? Cheng ----- Previous Message ---------------------------------------------------- To: Dan Nessett cc: ipsec @tis.com nat @livingston.com From: "Perry E. Metzger" @ UGATE Date: Wednesday February 4, 1998 03:59 PM Subject: Re: Interactions between IPSEC and NAT --------------------------------------------------------------------------- -------------------------------------------------------------------- ----------------------------------------------- Dan Nessett writes: > Anyone thought about this so that they can provide us with a nice clean > answer :-) ? Yes. If you want security, you can't use NAT, because by definition the thing NAT is trying to do (peek in and/or alter your packets) is what security is designed to prevent. Protocols like SSL have exactly the same issue, btw. Any protocol that protects the contents of your data will have the same issue. This is not fixable -- any "fixes" someone could propose to this would be so horrible as to make the entire point of security moot. Perry - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 00:05:41 1998 Delivery-Date: Thu, 05 Feb 1998 00:05:42 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id AAA03921 for ; Thu, 5 Feb 1998 00:05:40 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA23095; Wed, 4 Feb 1998 20:56:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA13103 for nat-outgoing; Wed, 4 Feb 1998 21:01:54 -0800 (PST) From: bound@zk3.dec.com Message-Id: <199802050500.AA03698@wasted.zk3.dec.com> To: Alex Alten Cc: perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Wed, 04 Feb 1998 19:46:15 PST." <3.0.3.32.19980204194615.0090c100@Netcom.Com> Date: Thu, 05 Feb 1998 00:00:47 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: bound@zk3.dec.com I think IPSEC has it right, and Perry gave us the bottom line many messages ago. I am talking to my friend Ray at X and I encrypt my packet which is the checksum and all stuff. IPSEC gives me the hope that NO ONE else can see the data including my ISP or routers or NAT boxes I don't even know, between me and Ray. I like the idea of not being violated on the Internet. I have already figured out to avoid NAT in most cases with IPv6 and now working on an NNAT for IPv4 if I can find someone who wants to do the writing? At first I thought DHCPv4 could not do NNAT but now I think it can though it does not have the Reconfigure msg of DHCPv6 I think we can do it with Multicast packets. The other option is to use DHCPv6 for IPv4 nodes too, which is possible. For those that want IPSEC, but need a temporary address like NAT does, the goal is to just avoid using NAT and I think this is very doable. I am not saying that NAT cannot still be used cause it will at least until IPv6 is pervasive, but I think we (engineers) are trying to solve this problem in the wrong way. We should be working on solutions to avoid NAT when it is not an optimal way to do "business" on the Internet. Do we discuss such notions here or do we need to have an Avoidance of NAT BOF and eventual Working Group at the L.A. IETF? Changing IPSEC for NAT is a bad engineering idea IMO. /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 02:31:46 1998 Delivery-Date: Thu, 05 Feb 1998 02:31:47 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id CAA08466 for ; Thu, 5 Feb 1998 02:31:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA26201; Wed, 4 Feb 1998 23:14:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA18555 for nat-outgoing; Wed, 4 Feb 1998 23:19:55 -0800 (PST) Message-Id: <3.0.3.32.19980204232324.0092e5d0@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 04 Feb 1998 23:23:24 -0800 To: perry@piermont.com From: Alex Alten Subject: (NAT) Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050609.BAA03281@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Alex Alten At 01:09 AM 2/5/98 -0500, Perry E. Metzger wrote: > >Alex Alten writes: >> This is what bothers me about the direction IPSEC has taken. The >> addition of security should not break things like trusted NATs. > >The function of IPsec is to keep a packet from being touched or read >in transit. IP packets are designed with routing in mind. There are fields which need to be adjusted between hops. This means IP security can only be designed with a single hop in mind. This also means that IP security must be part of a complete security system, of which IP security is just one component, the component which protects inter-router hops. A secure, trusted NAT can certainly be part of that system. >> If not, then encrypt the IP header, since all the trusted routers >> can decrypt it, decide how to route it, and then re-encrypt before >> transmitting it. > >We don't do that, actually. You can't bring all the routers on the >internet into your security perimeter -- that simply won't work. Thus, >we don't try. IPsec works via encapsulation -- the outer IP address is >in the clear, as it must be for routing to work. This is realistic, I stated this as my alternative. However the outer IP address must be at least be verified somehow, either via a MAC over it or duplicate routing information inside the protected encapsulation area. >For stuff like NAT to work you would need to include all NAT boxes and >routers in your security perimeter, and I fundamentally cannot think >of a design for this stuff that will work and will involve arbitrary >numbers of intermediate nodes on the global internet -- I belive that >it just can't be done in practice. Maybe I'm just not bright enough, >but I think that instead its an issue of having enough arrows in my >back to know better. > I absolutely agree. In fact, regardless of NAT, all the routers must be part of the security system (or security perimeter). For an arbitrary number of insecure routers, then I think only a transport or application level security will work. >> The really difficult issues of how to establish and control the >> network of trusted nodes, and how to implement and enforce >> network-wide policy can then be tackled. > >When you come up with a functioning protocol, let us know. I don't >believe one is possible, but I'm more than willing to listen. > Admittedly it is a tough problem to solve, given the datagram nature of IP and its high performance requirements for routing. It's much easier to do it at the TCP level. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 04:05:26 1998 Delivery-Date: Thu, 05 Feb 1998 04:05:27 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id EAA09019 for ; Thu, 5 Feb 1998 04:05:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA28314; Thu, 5 Feb 1998 00:55:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA22346 for nat-outgoing; Thu, 5 Feb 1998 01:00:03 -0800 (PST) Message-Id: <3.0.3.32.19980205010331.0091b6f0@Netcom.Com> X-Sender: andrade@Netcom.Com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 05 Feb 1998 01:03:31 -0800 To: perry@piermont.com From: Alex Alten Subject: (NAT) Re: Interactions between IPSEC and NAT Cc: ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050739.CAA05166@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Alex Alten At 02:39 AM 2/5/98 -0500, Perry E. Metzger wrote: >Maybe you ought to read the spec. It might answer a lot of your >questions. Believe it or not, we did know what we were doing. I have to really question if you knew what you were doing. Go read Rogaway's cryptographic analysis--have you fixed the issues he raised? Are you still seriously considering a PK solution for managing trust? If so, then God help anybody that has to implement it and get a real customer to use it. >Your viewpoint is a wee bit unrealistic -- there is, in practice, no >way to make even a tiny fraction of the routers trusted. It is also >unneeded -- we know how to provide security in a network where nothing >except the endpoints need to be trusted. Unfortunately you have come up with a solution I find cumbersome, slow, difficult to administer, with an awkward trust model, no auditing, and no key recovery. > Might I suggest that you >study this topic a bit more in depth before commenting further? You know Perry, not everyone who studies this field goes off and wastes their time writing RFC's and I-D's. I prefer to apply for patents and sell them. - Alex -- Alex Alten Andrade@Netcom.Com P.O. Box 11406 Pleasanton, CA 94588 USA (510) 417-0159 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 05:05:24 1998 Delivery-Date: Thu, 05 Feb 1998 05:05:24 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id FAA09528 for ; Thu, 5 Feb 1998 05:05:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA29102; Thu, 5 Feb 1998 01:55:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA24275 for nat-outgoing; Thu, 5 Feb 1998 02:00:11 -0800 (PST) Date: Thu, 5 Feb 1998 09:55:18 +0000 (GMT) From: George Tsirtsis To: bound@zk3.dec.com Cc: Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: George Tsirtsis Jim, On Thu, 5 Feb 1998 bound@zk3.dec.com wrote: > > I have already figured out to avoid NAT in most cases with IPv6 and now > working on an NNAT for IPv4 if I can find someone who wants to do the > writing? At first I thought DHCPv4 could not do NNAT but now I think it > can though it does not have the Reconfigure msg of DHCPv6 I think we can > do it with Multicast packets. The other option is to use DHCPv6 for > IPv4 nodes too, which is possible. Glad to hear that you desided to work on that. I always thought it was a good idea. > > For those that want IPSEC, but need a temporary address like NAT does, > the goal is to just avoid using NAT and I think this is very doable. Exactly! 'NAT bypass' is one way to do that and I hope you will find out another. > > I am not saying that NAT cannot still be used cause it will at least > until IPv6 is pervasive, but I think we (engineers) are trying to solve > this problem in the wrong way. We should be working on solutions to > avoid NAT when it is not an optimal way to do "business" on the Internet. In all this thread of discussion three solutions for NAT and IPSEC coexistance have been proposed. 1) Implement NAT and IPSEC at the same node. This can give you gateway to gateway security. 2) Do the above plus IPSEC between end-user and NAT. This can only work if the NAT is trusted and will give a kind fo end to end security, thought, a lot of people will argue with this... 3) Try to avoid NAT when IPSEC (or other end-to-end sensitive app.) is required. 'NAT bypass' attempts to do exactly that by building an l2tp tunnel (nothing to do with IPSEC tunnels) between itself and the NAT. The NAT then sends a global IP address through the tunnel and the host can now use the globally valid IP address to do IPSEC end-to-end, bypassing the NAT function. > > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? > I think NAT BOF (WG?) should be OK for that. I think NAT BOF was not about making NAT work, it was more about addressing the problems that NAT introduces. > Changing IPSEC for NAT is a bad engineering idea IMO. Agree! > > /jim > Best Regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 11:04:33 1998 Delivery-Date: Thu, 05 Feb 1998 11:04:33 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13347 for ; Thu, 5 Feb 1998 11:04:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA05543; Thu, 5 Feb 1998 07:48:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA08914 for nat-outgoing; Thu, 5 Feb 1998 07:53:27 -0800 (PST) Date: Thu, 5 Feb 1998 10:49:44 -0500 (EST) Message-Id: <199802051549.KAA05251@carp.morningstar.com> From: Ben Rogers To: bound@zk3.dec.com Cc: Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> References: <3.0.3.32.19980204194615.0090c100@Netcom.Com> <199802050500.AA03698@wasted.zk3.dec.com> Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Ben Rogers bound@zk3.dec.com writes: > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? >From the proposed NAT WG charter: The second set of documents will specify NAT friendly application and protocol design guidelines, interactions between NATs and applications such as DNS and protocols such as IP sec and mobile IP. The documents would also be extended to identify areas where NATs or other protocols and applications can be improved to overcome the shortcomings in interoperability or functionality. Due to the importance of the issue, specific attention will be given to the problems created by NATs for security protocols such as IPsec. Which makes it sound as if they're planning to be handling such issues. I know that one of the important points mentioned in the Washington was that if NAT were going to fly as a WG it would need to work around the security interactions by modifications to the way we do NAT instead of modifications to the way we do security. ben - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 11:22:26 1998 Delivery-Date: Thu, 05 Feb 1998 11:22:28 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13606 for ; Thu, 5 Feb 1998 11:22:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA06222; Thu, 5 Feb 1998 08:08:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA10559 for nat-outgoing; Thu, 5 Feb 1998 08:14:10 -0800 (PST) Message-Id: <199802051604.LAA05486@jekyll.piermont.com> To: Alex Alten cc: perry@piermont.com, ipsec@tis.com, nat@livingston.com Subject: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 1998 01:03:31 PST." <3.0.3.32.19980205010331.0091b6f0@Netcom.Com> X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 11:04:21 -0500 From: "Perry E. Metzger" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Perry E. Metzger" Alex Alten writes: > At 02:39 AM 2/5/98 -0500, Perry E. Metzger wrote: > >Maybe you ought to read the spec. It might answer a lot of your > >questions. Believe it or not, we did know what we were doing. > > I have to really question if you knew what you were doing. Go [...flamage deleted...] > You know Perry, not everyone who studies this field goes off and wastes > their time writing RFC's and I-D's. I prefer to apply for patents and sell > them. You will pardon me, but I'm going to cut this off now. I really don't think this is going to be productive for people, and most people probably don't want to read any more comments from me, especially as your comments speak for themselves. Nothing I could possibly say was as damaging to you as your own words. Perry - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 11:42:57 1998 Delivery-Date: Thu, 05 Feb 1998 11:42:57 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA13914 for ; Thu, 5 Feb 1998 11:42:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA07002; Thu, 5 Feb 1998 08:28:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA12535 for nat-outgoing; Thu, 5 Feb 1998 08:34:03 -0800 (PST) Message-Id: <199802051632.LAA05572@jekyll.piermont.com> To: Cheng_Chen@3com.com cc: "Perry E. Metzger" , Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Subject: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Wed, 04 Feb 1998 18:55:07 EST." <852565A1.0082AA92.00@hqoutbound.ops.3com.com> X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Feb 1998 11:32:46 -0500 From: "Perry E. Metzger" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Perry E. Metzger" Cheng_Chen@3com.com writes: > We all lock our house every morning when we go to work, although we know > that any average thief will be able to break it. So many of us pay $3000 > to install the home security system, although we know that any average > thief will cut your power line to disable the security system before they > enter the house. NAT is valuable to many people. As a NAT user, a less > than perfect security is better than NO security at all. Don't you lock > your front door every morning? Imagine that you have the choice between a $10 lock that works perfectly and is highly secure, or a $1000 lock that requires that a thief sneeze at it for it to open itself. Which would you choose? IPsec is a simple yet very secure protocol. You are proposing making it complicated and costly in an effort to remove all the protection it would provide. I am not sure that there is a point to that. An IPsec with the ability to modify the packets in flight is like a contraceptive that lets you get pregnant. "All the disadvantages of condoms, with all the disadvantages of pregnancy and and AIDS combined!" Why would anyone want such a thing? Perry - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 11:57:00 1998 Delivery-Date: Thu, 05 Feb 1998 11:57:00 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id LAA14083 for ; Thu, 5 Feb 1998 11:56:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA07648; Thu, 5 Feb 1998 08:44:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA14273 for nat-outgoing; Thu, 5 Feb 1998 08:49:40 -0800 (PST) Message-Id: <199802051648.IAA29194@puli.cisco.com> To: "Perry E. Metzger" cc: Cheng_Chen@3com.com, Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 98 11:32:46 EST." <199802051632.LAA05572@jekyll.piermont.com> Date: Thu, 05 Feb 98 08:48:27 PST From: Yakov Rekhter Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Yakov Rekhter Perry, > Cheng_Chen@3com.com writes: > > We all lock our house every morning when we go to work, although we know > > that any average thief will be able to break it. So many of us pay $3000 > > to install the home security system, although we know that any average > > thief will cut your power line to disable the security system before they > > enter the house. NAT is valuable to many people. As a NAT user, a less > > than perfect security is better than NO security at all. Don't you lock > > your front door every morning? > > Imagine that you have the choice between a $10 lock that works > perfectly and is highly secure, or a $1000 lock that requires that a > thief sneeze at it for it to open itself. Which would you choose? > > IPsec is a simple yet very secure protocol. You are proposing making > it complicated and costly in an effort to remove all the protection it > would provide. I am not sure that there is a point to that. > > An IPsec with the ability to modify the packets in flight is like a > contraceptive that lets you get pregnant. "All the disadvantages of > condoms, with all the disadvantages of pregnancy and and AIDS > combined!" Why would anyone want such a thing? Let me just say that some of the assumptions that IPsec was designed with don't match reality. On the orthogonal, yet somewhat related topic, it may be wise to remember that "reality has a way of adjusting those who think they can adjust it". Yakov. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 12:36:14 1998 Delivery-Date: Thu, 05 Feb 1998 12:36:15 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id MAA14494 for ; Thu, 5 Feb 1998 12:36:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA09138; Thu, 5 Feb 1998 09:22:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA17146 for nat-outgoing; Thu, 5 Feb 1998 09:24:05 -0800 (PST) Message-ID: <19980205122425.49108@hazel> Date: Thu, 5 Feb 1998 12:24:25 -0500 From: Raul Miller To: perry@piermont.com Cc: Cheng_Chen@3com.com, Dan Nessett , nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com Subject: (NAT) Re: Interactions between IPSEC and NAT References: <852565A1.0082AA92.00@hqoutbound.ops.3com.com> <199802051632.LAA05572@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199802051632.LAA05572@jekyll.piermont.com>; from Perry E. Metzger on Thu, Feb 05, 1998 at 11:32:46AM -0500 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Raul Miller Cheng_Chen@3com.com writes: > > We all lock our house every morning when we go to work, although we know > > that any average thief will be able to break it. So many of us pay $3000 > > to install the home security system, although we know that any average > > thief will cut your power line to disable the security system before they > > enter the house. NAT is valuable to many people. As a NAT user, a less > > than perfect security is better than NO security at all. Don't you lock > > your front door every morning? Multiplication isn't fast enough, I want to modify it so that I can continue to use all my algorithms which are based on addition without any modification... To someone that uses addition, a less than perfect solution is better than NO solution at all. Don't you balance your checkbook? -- Raul, didn't bother sending this to ipsec... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 13:12:16 1998 Delivery-Date: Thu, 05 Feb 1998 13:12:28 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id NAA15287 for ; Thu, 5 Feb 1998 13:12:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA10872; Thu, 5 Feb 1998 10:04:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA22314 for nat-outgoing; Thu, 5 Feb 1998 10:09:54 -0800 (PST) Message-Id: <199802051803.KAA10792@bast.livingston.com> To: ben@ascend.com (Ben Rogers) cc: bound@zk3.dec.com, Alex Alten , perry@piermont.com, Dan Nessett , ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-reply-to: Your message of "Thu, 05 Feb 1998 10:49:44 EST." <199802051549.KAA05251@carp.morningstar.com> Date: Thu, 05 Feb 1998 10:08:56 -0800 From: "Derrell D. Piper" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Derrell D. Piper" >I know that one of the important points mentioned in the Washington was >that if NAT were going to fly as a WG it would need to work around the >security interactions by modifications to the way we do NAT instead of >modifications to the way we do security. There's a good idea! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 14:20:13 1998 Delivery-Date: Thu, 05 Feb 1998 14:20:14 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA16101 for ; Thu, 5 Feb 1998 14:20:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA13818; Thu, 5 Feb 1998 11:11:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA29147 for nat-outgoing; Thu, 5 Feb 1998 11:15:51 -0800 (PST) From: Pyda Srisuresh Message-Id: <199802051915.LAA29141@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Thu, 5 Feb 1998 11:19:24 -0800 (PST) Cc: Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802050500.AA03698@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 5, 98 00:00:47 am Content-Type: text Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Jim, > > > I think IPSEC has it right, and Perry gave us the bottom line many > messages ago. > You may be right. There are tradeoffs and limitations to everything including IPSec. Other members of the list including Yakov and Alex ALten pointed this out eloquently. So, I wont go into this. > I am talking to my friend Ray at X and I encrypt my packet which is the > checksum and all stuff. IPSEC gives me the hope that NO ONE else can > see the data including my ISP or routers or NAT boxes I don't even know, > between me and Ray. I like the idea of not being violated on the > Internet. > If you consider NAT as a violation of your rights, you probably ought not use NAT. I can understand. But, you may have no choice if you are communcating with vendors that do use NATs in their setup. NAT has its place in providing solutions to a set of problems. The level of security required is not universal to all. > I have already figured out to avoid NAT in most cases with IPv6 and now > working on an NNAT for IPv4 if I can find someone who wants to do the > writing? At first I thought DHCPv4 could not do NNAT but now I think it > can though it does not have the Reconfigure msg of DHCPv6 I think we can > do it with Multicast packets. The other option is to use DHCPv6 for > IPv4 nodes too, which is possible. > Well, Jim, your proposal is not without its limitations and does not solve the many problems that NAT does. It is not a replacement for NATs and here are some reasons why. a) NATs do address and port translation. Your draft, which is based on DNS and DHCP v6 does not. b) Load Share NATs do session binding and load sharing on a real-time basis. Real-time address updates of DNS, in the past, at best are proved to be slow to adapt and have not been successful. And, your draft does not solve the load share problem that NATs do. c) NATs do flow-based address asignment and translations. Your draft tries to divert flow based address assignment (limited only to sessions originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to V4+V6 nodes. The end nodes must be sensitive to who they are talking to (V4 only or V4+v6 nodes), adapt multiple addresses (for incoming or outgoing sessions) and choose a routing scheme based on who they are talking to etc.. > For those that want IPSEC, but need a temporary address like NAT does, > the goal is to just avoid using NAT and I think this is very doable. > Surely, there are alternatives to meeting the IPSec requirements even with NATs in between. > I am not saying that NAT cannot still be used cause it will at least > until IPv6 is pervasive, but I think we (engineers) are trying to solve > this problem in the wrong way. We should be working on solutions to > avoid NAT when it is not an optimal way to do "business" on the Internet. > The meaning of the terms you use are subject to interpretation. What is "right", what is "optimal" and what it takes to do "business" - all vary considerably from observer to observer. > Do we discuss such notions here or do we need to have an Avoidance of > NAT BOF and eventual Working Group at the L.A. IETF? > This a NAT mailing list and you are airing your thoughts on the list; which I appreciate. We are in the process of trying to form a NAT work group, trying to get the language for charter just right so it is agreeable to IESG, IAB, Area advisors and WG chairs. The process has been slower than I would like; but we are progressing... Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at LA? Why do you feel the need to avoid the NAT forum. I do not appreciate your doing this. Is that because you believe NATs are the "wrong" way to solve business problems. We went over this in the Munich BOF; And, the majority of people in Munich as well as Washington BOF felt it a good idea to have NAT work group. > Changing IPSEC for NAT is a bad engineering idea IMO. > I refer you to the charter and objectives stated for the BOFs in Munich and Washington, DC. There was no such mention. We dont intend adding this terminology to the eventual Work group charter either. > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > Regards, suresh - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 15:04:41 1998 Delivery-Date: Thu, 05 Feb 1998 15:04:41 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA16946 for ; Thu, 5 Feb 1998 15:04:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA15647; Thu, 5 Feb 1998 11:57:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA03918 for nat-outgoing; Thu, 5 Feb 1998 12:03:16 -0800 (PST) From: "Alexei V. Vopilov" To: "Ben Rogers" , Cc: "Alex Alten" , , "Dan Nessett" , , Subject: Re: (NAT) Re: Interactions between IPSEC and NAT Date: Thu, 5 Feb 1998 22:51:12 +0300 Message-ID: <01bd326f$69090780$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Alexei V. Vopilov" -----Original Message----- From: Ben Rogers To: bound@zk3.dec.com Cc: Alex Alten ; perry@piermont.com ; Dan Nessett ; ipsec@tis.com ; nat@livingston.com Date: 5 февраля 1998 г. 20:51 Subject: Re: (NAT) Re: Interactions between IPSEC and NAT [ . . .] :Which makes it sound as if they're planning to be handling such issues. :I know that one of the important points mentioned in the Washington was :that if NAT were going to fly as a WG it would need to work around the :security interactions by modifications to the way we do NAT instead of :modifications to the way we do security. : :ben If this is a 'hint', it makes NAT people to just give up with IPsec since they have nothing to do after an IPsec transform is done. If IPsec wg ignores the NAT one, that actually would affect the customer base for both technologies. --Alexei - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 15:52:28 1998 Delivery-Date: Thu, 05 Feb 1998 15:52:29 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id PAA17794 for ; Thu, 5 Feb 1998 15:52:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA16923; Thu, 5 Feb 1998 12:45:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA07492 for nat-outgoing; Thu, 5 Feb 1998 12:51:04 -0800 (PST) Message-Id: <199802052049.UAA09443@orchard.arlington.ma.us> To: Yakov Rekhter cc: "Perry E. Metzger" , Cheng_Chen@3com.com, Dan Nessett , ipsec@tis.com, nat@livingston.com, paul_douglas@3com.com, raj_bhatia@3com.com, ken_araujo@3com.com In-reply-to: Your message of "Thu, 5 Feb 1998 12:47:46 -0500 (EST) ." <199802051648.IAA29194@puli.cisco.com> Date: Thu, 05 Feb 1998 15:48:27 -0500 From: Bill Sommerfeld Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Bill Sommerfeld Yakov, You seem to be characterizing this as a "ipsec vs. NAT" debate. It's really a "security vs. NAT" debate. Over the past 10 years, I've worked on a number of different systems with integrated crytographic security which, among other things, often cryptographically protect IP addresses from modification... either at the network layer, like ipsec, or above it in the application layer. Every single one of these systems is broken by NAT. Every single one. This says quite a bit about the violence which NAT does to the goal of securing the Internet. - Bill - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Feb 5 16:43:21 1998 Delivery-Date: Thu, 05 Feb 1998 16:43:22 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.7/8.8.7a) with ESMTP id QAA18637 for ; Thu, 5 Feb 1998 16:43:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA18605; Thu, 5 Feb 1998 13:34:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA11834 for nat-outgoing; Thu, 5 Feb 1998 13:37:39 -0800 (PST) From: bound@zk3.dec.com Message-Id: <199802052135.AA29211@wasted.zk3.dec.com> To: Pyda Srisuresh Cc: bound@zk3.dec.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Thu, 05 Feb 1998 11:19:24 PST." <199802051915.LAA29141@server.livingston.com> Date: Thu, 05 Feb 1998 16:35:48 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: bound@zk3.dec.com Suresh, > I think IPSEC has it right, and Perry gave us the bottom line many > messages ago. >You may be right. There are tradeoffs and limitations to everything >including IPSec. Other members of the list including Yakov and Alex >ALten pointed this out eloquently. So, I wont go into this. As someone just said its not an IPSEC vs NAT its Security vs NAT and I would even say Private Addresses vs using real Internet Addresses which is causing NAT. >> I am talking to my friend Ray at X and I encrypt my packet which is the >> checksum and all stuff. IPSEC gives me the hope that NO ONE else can >> see the data including my ISP or routers or NAT boxes I don't even know, >> between me and Ray. I like the idea of not being violated on the >> Internet. >If you consider NAT as a violation of your rights, you probably ought not >use NAT. I can understand. But, you may have no choice if you are >communcating with vendors that do use NATs in their setup. NAT has its >place in providing solutions to a set of problems. The level of security >required is not universal to all. If I do not have the choice to use end to end security on the Internet then a very serious choice for nodes is missing. Once we deploy IPv6 and IPSEC and other forms that do not need private addresses then I agree with Yakov folks will have to change their mind, only my view of where the world will go is far different from Yakov's I think. >> I have already figured out to avoid NAT in most cases with IPv6 and now >> working on an NNAT for IPv4 if I can find someone who wants to do the >> writing? At first I thought DHCPv4 could not do NNAT but now I think it >> can though it does not have the Reconfigure msg of DHCPv6 I think we can >> do it with Multicast packets. The other option is to use DHCPv6 for >> IPv4 nodes too, which is possible. >> >Well, Jim, your proposal is not without its limitations and does not solve >the many problems that NAT does. It is not a replacement for NATs and >here are some reasons why. Of course my draft has limitations I am not clear I agree with you on what the defintion of a limitation is vs an advantage though. > a) NATs do address and port translation. Your draft, which is based on > DNS and DHCP v6 does not. I consider this an advantage. > b) Load Share NATs do session binding and load sharing on a real-time > basis. Real-time address updates of DNS, in the past, at best are > proved to be slow to adapt and have not been successful. And, your > draft does not solve the load share problem that NATs do. Load Share is a side benefit of NAT we can have load shire without NAT. My draft does not prevent load share. > c) NATs do flow-based address asignment and translations. Your draft > tries to divert flow based address assignment (limited only to sessions > originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to > V4+V6 nodes. The end nodes must be sensitive to who they are talking > to (V4 only or V4+v6 nodes), adapt multiple addresses (for > incoming or outgoing sessions) and choose a routing scheme based > on who they are talking to etc.. Yes my draft is to help users not have to have private addresses and can move to the Next Generation Internet Protocol which is IPv6 more expediently and does not require any translation. The only cost is a one time set up. As far as providing flow based or IP Switched benefits that is not a function of NAT and can be provided once the node has a real IPv4 address. But this is a philosophical discussion and not technical so I will stop. Please don't try to tell me that packets can move faster for IPv4 with NAT than if NAT was not needed and the node has a real IPv4 Internet address where NAT is not needed. I don't believe that at all. >> For those that want IPSEC, but need a temporary address like NAT does, >> the goal is to just avoid using NAT and I think this is very doable. >Surely, there are alternatives to meeting the IPSec requirements even with >NATs in between. Well I just read the mobile draft for firewalls. I think its good work but it has much cost and requires some serious security dynamics to provide end-to-end security. In addition it only works public to private now not private to private across the Internet. I will read George's by-pass draft this weekend. I don't think its possible given the "trust" model assumed. We can change the trust model but that gets into philosophy too not engineering. Changing the philosophy of our trust model will take awhile IMO, but thats not in this WG charter and we should probably take that discussion elswhere. >> I am not saying that NAT cannot still be used cause it will at least >> until IPv6 is pervasive, but I think we (engineers) are trying to solve >> this problem in the wrong way. We should be working on solutions to >> avoid NAT when it is not an optimal way to do "business" on the Internet. >The meaning of the terms you use are subject to interpretation. What >is "right", what is "optimal" and what it takes to do "business" - all vary >considerably from observer to observer. Well let me interpret it clearer for you. Laissez-faire. NAT is fine but building alternatives to NAT is fine too. I hope that is clearer. >> Do we discuss such notions here or do we need to have an Avoidance of >> NAT BOF and eventual Working Group at the L.A. IETF? >This a NAT mailing list and you are airing your thoughts on the list; >which I appreciate. We are in the process of trying to form a NAT work >group, trying to get the language for charter just right so it is >agreeable to IESG, IAB, Area advisors and WG chairs. The process has >been slower than I would like; but we are progressing... >Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at >LA? Why do you feel the need to avoid the NAT forum. I do not appreciate >your doing this. Is that because you believe NATs are the "wrong" way to >solve business problems. We went over this in the Munich BOF; And, the >majority of people in Munich as well as Washington BOF felt it a good >idea to have NAT work group. Your misunderstanding my words. I do think we need a NAT WG and charter. But based on a lot of mail here I also think we in the IETF need to work on alternatives to NAT or translation. The question is should that be part of this WG? I don't know? I go to NAT now (when I don't have other conflicts) and if there is a group doing an alternative to NAT I will go there too. I am not against this work and believe it to be important because it exists in the market. But I believe it better to not use private addresses for many reasons and that is the only reason for NAT in the market I can justify. >> Changing IPSEC for NAT is a bad engineering idea IMO. >I refer you to the charter and objectives stated for the BOFs in >Munich and Washington, DC. There was no such mention. We dont intend >adding this terminology to the eventual Work group charter either. This was just a comment to the list thats all as some suggested if IPSEC don't work with NAT then IPSEC maybe should be changed. So I was responding to that mail. Sincerely, /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 6 17:52:56 1998 Delivery-Date: Fri, 06 Feb 1998 17:52:56 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA17625 for ; Fri, 6 Feb 1998 17:52:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA27600; Fri, 6 Feb 1998 14:40:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA22401 for nat-outgoing; Fri, 6 Feb 1998 14:41:55 -0800 (PST) From: Pyda Srisuresh Message-Id: <199802062241.OAA22388@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Fri, 6 Feb 1998 14:45:29 -0800 (PST) Cc: suresh@livingston.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802052135.AA29211@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 5, 98 04:35:48 pm Content-Type: text Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Jim, Thanks for your response and clarifications. Please note my comments below. cheers, suresh > > Suresh, > .... stuff deleted. > >If you consider NAT as a violation of your rights, you probably ought not > >use NAT. I can understand. But, you may have no choice if you are > >communcating with vendors that do use NATs in their setup. NAT has its > >place in providing solutions to a set of problems. The level of security > >required is not universal to all. > > If I do not have the choice to use end to end security on the Internet > then a very serious choice for nodes is missing. Once we deploy IPv6 > and IPSEC and other forms that do not need private addresses then I > agree with Yakov folks will have to change their mind, only my view of > where the world will go is far different from Yakov's I think. > Fair enough. Time will tell. > >> I have already figured out to avoid NAT in most cases with IPv6 and now > >> working on an NNAT for IPv4 if I can find someone who wants to do the > >> writing? At first I thought DHCPv4 could not do NNAT but now I think it > >> can though it does not have the Reconfigure msg of DHCPv6 I think we can > >> do it with Multicast packets. The other option is to use DHCPv6 for > >> IPv4 nodes too, which is possible. > >> > > >Well, Jim, your proposal is not without its limitations and does not solve > >the many problems that NAT does. It is not a replacement for NATs and > >here are some reasons why. > > Of course my draft has limitations I am not clear I agree with you on > what the defintion of a limitation is vs an advantage though. > > > a) NATs do address and port translation. Your draft, which is based on > > DNS and DHCP v6 does not. > > I consider this an advantage. > > > b) Load Share NATs do session binding and load sharing on a real-time > > basis. Real-time address updates of DNS, in the past, at best are > > proved to be slow to adapt and have not been successful. And, your > > draft does not solve the load share problem that NATs do. > > Load Share is a side benefit of NAT we can have load shire without NAT. > My draft does not prevent load share. > > > c) NATs do flow-based address asignment and translations. Your draft > > tries to divert flow based address assignment (limited only to sessions > > originating from V4 to V4+V6 nodes) through DHCP v6 and DNS to > > V4+V6 nodes. The end nodes must be sensitive to who they are talking > > to (V4 only or V4+v6 nodes), adapt multiple addresses (for > > incoming or outgoing sessions) and choose a routing scheme based > > on who they are talking to etc.. > > Yes my draft is to help users not have to have private addresses and can > move to the Next Generation Internet Protocol which is IPv6 more > expediently and does not require any translation. The only cost is a > one time set up. Yes, my point is simply that the proposal in your draft is a solution to a problem, relating to transition from V4 to V6. It has its limitations as well. The solution path you identified in no way is a panacea to all problems NAT purports to solve and as such is far from being a replacement to NAT solution. I think, you agree with with me on this. If so, no need to belabor on this point any further. > As far as providing flow based or IP Switched benefits > that is not a function of NAT and can be provided once the node has a > real IPv4 address. But this is a philosophical discussion and not > technical so I will stop. > Yes, NAT is a flow based address assignment tool (unlike DHCP, which is simply a resource manager). You may be confusing this with flow based switching by IP routers. These are two different things. > Please don't try to tell me that packets can move faster for IPv4 with > NAT than if NAT was not needed and the node has a real IPv4 Internet > address where NAT is not needed. I don't believe that at all. > The session setup latency is certainly much smaller with NATs, which assign addresses dynamically vs. a set up that involves DHCP and DNS record updates. Also, with NAT, routing is transparant to end nodes. > >> For those that want IPSEC, but need a temporary address like NAT does, > >> the goal is to just avoid using NAT and I think this is very doable. > > >Surely, there are alternatives to meeting the IPSec requirements even with > >NATs in between. > > Well I just read the mobile draft for firewalls. I think its good work > but it has much cost and requires some serious security dynamics to > provide end-to-end security. In addition it only works public to > private now not private to private across the Internet. I will read > George's by-pass draft this weekend. > > I don't think its possible given the "trust" model assumed. We can > change the trust model but that gets into philosophy too not > engineering. Changing the philosophy of our trust model will take > awhile IMO, but thats not in this WG charter and we should probably take > that discussion elswhere. > > >> I am not saying that NAT cannot still be used cause it will at least > >> until IPv6 is pervasive, but I think we (engineers) are trying to solve > >> this problem in the wrong way. We should be working on solutions to > >> avoid NAT when it is not an optimal way to do "business" on the Internet. > > >The meaning of the terms you use are subject to interpretation. What > >is "right", what is "optimal" and what it takes to do "business" - all vary > >considerably from observer to observer. > > Well let me interpret it clearer for you. Laissez-faire. NAT is fine > but building alternatives to NAT is fine too. I hope that is clearer. > Exactly my point. Thanks for the clarification. > >> Do we discuss such notions here or do we need to have an Avoidance of > >> NAT BOF and eventual Working Group at the L.A. IETF? > > >This a NAT mailing list and you are airing your thoughts on the list; > >which I appreciate. We are in the process of trying to form a NAT work > >group, trying to get the language for charter just right so it is > >agreeable to IESG, IAB, Area advisors and WG chairs. The process has > >been slower than I would like; but we are progressing... > > >Why are you advocating boycott of the upcoming NAT BOF and/or NAT WG at > >LA? Why do you feel the need to avoid the NAT forum. I do not appreciate > >your doing this. Is that because you believe NATs are the "wrong" way to > >solve business problems. We went over this in the Munich BOF; And, the > >majority of people in Munich as well as Washington BOF felt it a good > >idea to have NAT work group. > > Your misunderstanding my words. I do think we need a NAT WG and > charter. But based on a lot of mail here I also think we in the IETF > need to work on alternatives to NAT or translation. The question is > should that be part of this WG? I don't know? I go to NAT now (when I > don't have other conflicts) and if there is a group doing an alternative > to NAT I will go there too. I am not against this work and believe it > to be important because it exists in the market. But I believe it > better to not use private addresses for many reasons and that is the > only reason for NAT in the market I can justify. > Thanks again for your clarification. Apparantly, I parsed your sentence differently from what you expected. Anyways, here are my thoughts on the subject. We are planning to form NAT work group only because NATs are a reality and solve a set of problems in the real world; This is despite the fact that NATs do not share the mainstream IETF paradigm of "single routing realm". So, in a sense, the rest of IETF is already persuing solutions in the mainstream. And, NAT WG would be persuing a deviation from the mainstream. There are other work groups like "mobile IP" that share some of this theme. So, if you have a solution that is more in the mainstream, there may be already be some work groups in the mainstream that fit the bill. E.g.: ngtrans work group that deals with V4->V6 transition issues > >> Changing IPSEC for NAT is a bad engineering idea IMO. > > >I refer you to the charter and objectives stated for the BOFs in > >Munich and Washington, DC. There was no such mention. We dont intend > >adding this terminology to the eventual Work group charter either. > > This was just a comment to the list thats all as some suggested if IPSEC > don't work with NAT then IPSEC maybe should be changed. So I was > responding to that mail. > OK, I understand. > Sincerely, > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 6 18:32:43 1998 Delivery-Date: Fri, 06 Feb 1998 18:32:44 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18314 for ; Fri, 6 Feb 1998 18:32:42 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA28663; Fri, 6 Feb 1998 15:19:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA25892 for nat-outgoing; Fri, 6 Feb 1998 15:20:57 -0800 (PST) From: bound@zk3.dec.com Message-Id: <199802062306.AA11924@wasted.zk3.dec.com> To: Pyda Srisuresh Cc: bound@zk3.dec.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com Subject: Re: (NAT) Re: Interactions between IPSEC and NAT In-Reply-To: Your message of "Fri, 06 Feb 1998 14:45:29 PST." <199802062241.OAA22388@server.livingston.com> Date: Fri, 06 Feb 1998 18:06:01 -0500 X-Mts: smtp Sender: owner-nat@livingston.com Precedence: bulk Reply-To: bound@zk3.dec.com Suresh, I don't see belaboring these points further. I will agree that we disagree on the values and capabilities of NAT and thats fine, rather than provide anymore counter arguments, because I believe the point of this mail list and group is to develop the specifics that relate to that which can be standardized in the IETF to support NAT technology. So lets start having that discussion because I am an engineer who is interested and will build a NAT implementation as one solution to leave IPv4 and move on to IPv6 and avoid private addresses as ONE customer "choice" to accomplish this task. As far as other solutions that don't use NAT I take your mail this is not the place to work on that, though you put that politically quite well as other comments you have made now and in the past, which is good as your the chair and need to be nice to us. Thank You. Soooo... I will connect offline with a few folks and suggest we have a BOF potentially of alternative solutions to NAT. My work on NNAT is for v4-v6 transition and that clearly belongs in the NGTRANS WG I agree. But my engineering work on this has made me realize as an implementor I can implement alternatives to NAT and I will see if others in our community are interested in, in another forum. Including for IPv4 regardless of IPv6. So now I am also interested in solutions that can avoid NAT in IPv4 too. Others can send me mail PRIVATELY if you interested in such a BOF for the L.A. meeting. thanks for working to clear this up, /jim - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Feb 6 19:44:56 1998 Delivery-Date: Fri, 06 Feb 1998 19:44:56 -0500 Return-Path: owner-nat@livingston.com Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA18961 for ; Fri, 6 Feb 1998 19:44:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA00823; Fri, 6 Feb 1998 16:31:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA01718 for nat-outgoing; Fri, 6 Feb 1998 16:36:49 -0800 (PST) From: Pyda Srisuresh Message-Id: <199802070036.QAA01712@server.livingston.com> Subject: Re: (NAT) Re: Interactions between IPSEC and NAT To: bound@zk3.dec.com Date: Fri, 6 Feb 1998 16:40:24 -0800 (PST) Cc: suresh@livingston.com, Andrade@netcom.com, perry@piermont.com, Dan_Nessett@tdc.3com.com, ipsec@tis.com, nat@livingston.com In-Reply-To: <199802062306.AA11924@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Feb 6, 98 06:06:01 pm Content-Type: text Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh Jim, Thanks for your understanding. I am not trying to be political, just putting things in perspective. As for solutions that do not include NAT, I am not averse to them. I will certainly try to offer whatever I can towards providing myriad of solutions to customers. Thanks again. cheers, suresh > > Suresh, > > I don't see belaboring these points further. I will agree that we > disagree on the values and capabilities of NAT and thats fine, rather > than provide anymore counter arguments, because I believe the point of > this mail list and group is to develop the specifics that relate to that > which can be standardized in the IETF to support NAT technology. > > So lets start having that discussion because I am an engineer who is > interested and will build a NAT implementation as one solution to leave > IPv4 and move on to IPv6 and avoid private addresses as ONE customer > "choice" to accomplish this task. > > As far as other solutions that don't use NAT I take your mail this is > not the place to work on that, though you put that politically quite > well as other comments you have made now and in the past, which is good > as your the chair and need to be nice to us. Thank You. > > Soooo... I will connect offline with a few folks and suggest we have a > BOF potentially of alternative solutions to NAT. My work on NNAT is for > v4-v6 transition and that clearly belongs in the NGTRANS WG I agree. But > my engineering work on this has made me realize as an implementor I can > implement alternatives to NAT and I will see if others in our > community are interested in, in another forum. Including for IPv4 > regardless of IPv6. So now I am also interested in solutions that can > avoid NAT in IPv4 too. > > Others can send me mail PRIVATELY if you interested in such a BOF for > the L.A. meeting. > > thanks for working to clear this up, > /jim > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-ietf-outbound.10 Mon Feb 23 13:35:19 1998 Delivery-Date: Mon, 23 Feb 1998 13:37:24 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA21801 for ietf-outbound.10@ietf.org; Mon, 23 Feb 1998 13:35:02 -0500 (EST) Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA21712 for ; Mon, 23 Feb 1998 13:31:19 -0500 (EST) Received: (from marc@localhost) by rover.cygnus.com (8.8.8/8.6.12) id NAA13211; Mon, 23 Feb 1998 13:32:12 -0500 (EST) To: perry@piermont.com Cc: ietf@ns.ietf.org Subject: Re: IAB comments on Green Paper References: <199802231739.MAA12340@jekyll.piermont.com> From: Marc Horowitz Date: 23 Feb 1998 13:32:11 -0500 In-Reply-To: "Perry E. Metzger"'s message of Mon, 23 Feb 1998 12:39:14 -0500 Message-ID: Lines: 20 X-Mailer: Gnus v5.3/Emacs 19.34 "Perry E. Metzger" writes: >> Might I ask who appointed Ira Magaziner God in the first place? Clinton did. The voters of the US made Clinton President, and he apparently misread the Fine Print. >> So far as I know, U.S. law doesn't grant Mr. Magaziner plenipotentiary >> powers to dictate *anything* to the IETF. He can, of course, pretend >> that he can do so to his hearts content, but I don't see anything in >> the U.S. legal system that actually gives him the right to *do* >> anything. If I were you, I would be worried that Mr. Magaziner will pull an Executive Order out of his pocket. That's his legal trump card. IMNSHO, Noel is right. Move the sandbox to more friendly jurisdiction. Marc From owner-ietf-outbound.10 Mon Feb 23 14:00:10 1998 Delivery-Date: Mon, 23 Feb 1998 14:03:30 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA22614 for ietf-outbound.10@ietf.org; Mon, 23 Feb 1998 14:00:03 -0500 (EST) Received: from pax.cavebear.com (pax.cavebear.com [192.203.17.70]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA22550 for ; Mon, 23 Feb 1998 13:58:44 -0500 (EST) Received: from localhost (karl@localhost) by pax.cavebear.com (8.8.7/8.8.6) with SMTP id KAA02293; Mon, 23 Feb 1998 10:58:08 -0800 (PST) Date: Mon, 23 Feb 1998 10:58:08 -0800 (PST) From: Karl Auerbach X-Sender: karl@pax Reply-To: Karl Auerbach To: Marc Horowitz cc: perry@piermont.com, ietf@ns.ietf.org Subject: Re: IAB comments on Green Paper In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If I were you, I would be worried that Mr. Magaziner will pull an > Executive Order out of his pocket. That's his legal trump card. Please don't think that the President can just issue Executive Orders and make things happen. The President in the US has only rather limited intrinsic powers (mainly military and international relations.) Other powers come from statutes passed by Congress in which various jobs are assigned to the President or one of the various agencies. As an example of the limits on Executive Orders, note that the recent "Patients Bill of Rights" order was limited to only those things the President could reach under his delegated powers -- medical care systems which involve Federal people or money. It's important to not let ourselves assign to governmental authorities more power than they actually have. That path creates kings. I, for one, do not believe that the people behind the Proposal are acting in bad faith. (I do believe that they are undereducated about the issues and the technology.) It is extremely that people who have opinions on these matters, or who have good tutorial materials to help educate NTIA and other government-critters, submit cogent materials to the NTIA. (I'm expecting that after NTIA we will have another go-around or three before Congress. Then it'll go international.) --karl-- From owner-ietf-outbound.10 Mon Feb 23 14:40:23 1998 Delivery-Date: Mon, 23 Feb 1998 14:43:21 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA24427 for ietf-outbound.10@ietf.org; Mon, 23 Feb 1998 14:40:02 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA24266 for ; Mon, 23 Feb 1998 14:35:52 -0500 (EST) Received: from expresso.bunyip.com (expresso.Bunyip.Com [192.197.208.2]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id OAA18906; Mon, 23 Feb 1998 14:35:52 -0500 (EST) Message-Id: <199802231935.OAA18906@mocha.bunyip.com> Received: by expresso.bunyip.com (NX5.67c/NX3.0X) id AA15616; Mon, 23 Feb 98 14:35:30 -0500 From: Peter Deutsch Date: Mon, 23 Feb 1998 14:35:29 -0500 In-Reply-To: Karl Auerbach's message as of Feb 23, 10:58 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Karl Auerbach , Marc Horowitz Subject: Re: IAB comments on Green Paper Cc: perry@piermont.com, ietf@ns.ietf.org [ You wrote: ] } Please don't think that the President can just issue Executive Orders and } make things happen. } } The President in the US has only rather limited intrinsic powers (mainly } military and international relations.) So, if someone proposes moving DNS administration to Switzerland, he'd be within his powers to send in an airstrike?? :-) [* please note the smiley. This denotes a joke. A joke. A joke... *] - peterd -- ------------------------------------------------------------------------------ Peter Deutsch, (514) 875-8611 (phone) Bunyip Information Systems Inc. (514) 875-8134 (fax) http://www.bunyip.com "... When beetles fight these battles in a bottle with their paddles and the bottle's on a poodle and the poodle's eating noodles... they call this a muddle puddle tweedle poodle beetle noodle bottle paddle battle..." ---------------------------------------------------------------------------- From owner-ietf-outbound.10 Mon Feb 23 15:30:08 1998 Delivery-Date: Mon, 23 Feb 1998 15:34:25 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id PAA25758 for ietf-outbound.10@ietf.org; Mon, 23 Feb 1998 15:30:03 -0500 (EST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25677 for ; Mon, 23 Feb 1998 15:26:22 -0500 (EST) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id PAA12498; Mon, 23 Feb 1998 15:26:16 -0500 (EST) Message-Id: <199802232026.PAA12498@jekyll.piermont.com> To: Marc Horowitz cc: perry@piermont.com, ietf@ns.ietf.org Subject: Re: IAB comments on Green Paper In-reply-to: Your message of "23 Feb 1998 13:32:11 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 23 Feb 1998 15:26:15 -0500 From: "Perry E. Metzger" Marc Horowitz writes: > >> So far as I know, U.S. law doesn't grant Mr. Magaziner plenipotentiary > >> powers to dictate *anything* to the IETF. He can, of course, pretend > >> that he can do so to his hearts content, but I don't see anything in > >> the U.S. legal system that actually gives him the right to *do* > >> anything. > > If I were you, I would be worried that Mr. Magaziner will pull an > Executive Order out of his pocket. That's his legal trump card. Again, executive orders may only be made under circumstances prescribed by law. There is no legal authority here for any action by the administration. The only power they have here is that we're scared and have decided to act as though they had such power. Perhaps Congress might choose to give them such power in the future, but they have not yet seen fit to do so. I'm sure members of the administration like Mr. Magaziner frequently forget that they are bound to follow the law and mistake themselves *for* the law, but we are still governed by laws, not men. Perry From owner-ietf-outbound.10 Tue Feb 24 20:35:21 1998 Delivery-Date: Tue, 24 Feb 1998 20:36:54 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id UAA10465 for ietf-outbound.10@ietf.org; Tue, 24 Feb 1998 20:35:02 -0500 (EST) Received: from smtp2.mailsrvcs.net (smtp2.gte.net [207.115.153.31]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA10443 for ; Tue, 24 Feb 1998 20:34:27 -0500 (EST) Received: from 207-193-183-17.integragroup.net (207-193-183-17.integragroup.net [207.193.183.17]) by smtp2.mailsrvcs.net with SMTP id TAA04295 for ; Tue, 24 Feb 1998 19:34:25 -0600 (CST) Received: by 207-193-183-17.integragroup.net with Microsoft Mail id <01BD415B.71BFDA70@207-193-183-17.integragroup.net>; Tue, 24 Feb 1998 19:36:04 -0600 Message-ID: <01BD415B.71BFDA70@207-193-183-17.integragroup.net> From: Stu McClure To: "'perry@piermont.com'" , "ietf@ns.ietf.org" Subject: RE: do not feed the nutcase Date: Tue, 24 Feb 1998 19:36:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.ietf.org id UAA10444 Perry, You've hit this right on target! I've already filtered him out! We need serious people to talk about actual and current engineering practices. One of the reasons we have so many people unsubscribing every day is that our content is fading each and every day. Let's return to the substance we used to have. Let's return to the engineering topics we used to discuss instead of politics. P.S. Sorry Perry (Jon, Vint, et al) from those of us who still tune in ...for their lack of relativity. circa AHS -----Original Message----- From: Perry E. Metzger [SMTP:perry@piermont.com] Sent: Tuesday, February 24, 1998 11:24 AM To: ietf@ns.ietf.org Subject: do not feed the nutcase The more people reply to Jim Fleming, the less actual work we will accomplish. That is, of course, his likely goal here. (If that is not his goal and he is simply deranged there is no point in replying anyway.) I know there is a great temptation to reply and note "Jim, you have every detail totally wrong", but please just delete his messages unread instead. We have serious work to do. Perry From owner-ietf-outbound.10 Tue Feb 24 23:40:27 1998 Delivery-Date: Tue, 24 Feb 1998 23:43:08 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id XAA19734 for ietf-outbound.10@ietf.org; Tue, 24 Feb 1998 23:40:04 -0500 (EST) Received: from cybertron.div8.net (vektor@spc-isp-ott-uas-06-10.sprint.ca [209.103.34.11]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA19678 for ; Tue, 24 Feb 1998 23:37:15 -0500 (EST) Received: from localhost (vektor@localhost) by cybertron.div8.net (8.8.5/8.6.12) with SMTP id XAA09021; Tue, 24 Feb 1998 23:37:29 -0500 Date: Tue, 24 Feb 1998 23:37:29 -0500 (EST) From: Billy Biggs To: "Perry E. Metzger" cc: Lance Spitzner , Billy Biggs , Brian E Carpenter , ietf@ns.ietf.org Subject: Re: IAB comments on Green Paper In-Reply-To: <199802242337.SAA18111@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 24 Feb 1998, Perry E. Metzger wrote: > Lance Spitzner writes: > > o First, divorce TLDs from the technical community. Allow the > > Maybe you aren't aware of this, but we've gone through and debated the > whole thing very extensively -- the hard decisions were already > made. The IANA created the IAHC, which came up with a widely respected > solution, and a lot of organizations lined up behind it, and > organizations set up a nice portable registration system to make DNS > names portable the way that 800 numbers are portable, and then... > ....and then Ira Magaziner decided that he couldn't leave a good thing > alone. Perry, With the USG asserting right to 'the final say' in this matter, I think the technical community (IAB/IETF/IESG) has to realize which is important: control over the IANA functions or control of DNS. We MUST make sure that the IANA role is handed over to the IAB to find funding for. Losing the DNS issue is, in my opinion, an acceptable loss. [ Especially considering the world can choose to point at USG roots or ] [ point at CORE roots. :) ] This is what ITAG should address, no? First, confirming with Magaziner that the IANA roles of protocol assignment and IP space 'ownership' be handed over to the IAB to create an IANA-lite that will handle them. DNS political issues can then be fought out by public argument against the GP. Billy Biggs Division 8 Networks bbiggs@div8.net From owner-ietf-outbound.10 Wed Feb 25 11:30:29 1998 Delivery-Date: Wed, 25 Feb 1998 11:31:35 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA02486 for ietf-outbound.10@ietf.org; Wed, 25 Feb 1998 11:30:07 -0500 (EST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA02350 for ; Wed, 25 Feb 1998 11:27:59 -0500 (EST) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA20467; Wed, 25 Feb 1998 11:26:05 -0500 (EST) Message-Id: <199802251626.LAA20467@jekyll.piermont.com> To: Billy Biggs cc: "Perry E. Metzger" , Lance Spitzner , Billy Biggs , Brian E Carpenter , ietf@ns.ietf.org Subject: Re: IAB comments on Green Paper In-reply-to: Your message of "Tue, 24 Feb 1998 23:37:29 EST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Feb 1998 11:26:04 -0500 From: "Perry E. Metzger" Billy Biggs writes: > With the USG asserting right to 'the final say' in this matter, What if you tomorrow morning asserted that you were the world emperor and requested that we all wear funny hats. Would we actually have to wear funny hats? Perry From owner-ietf-outbound.10 Wed Feb 25 16:25:18 1998 Delivery-Date: Wed, 25 Feb 1998 16:29:03 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id QAA09938 for ietf-outbound.10@ietf.org; Wed, 25 Feb 1998 16:25:02 -0500 (EST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA09844 for ; Wed, 25 Feb 1998 16:23:05 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA75544; Wed, 25 Feb 1998 16:22:27 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA38520; Wed, 25 Feb 1998 16:22:31 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id QAA02784; Wed, 25 Feb 1998 16:22:28 -0500 (EST) Message-Id: <199802252122.QAA02784@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: perry@piermont.com cc: Scott Bradner , ietf@ns.ietf.org Subject: Re: from Ira Magaziner Re: IETF relationship to new IANA In-reply-to: Your message of "Wed, 25 Feb 1998 11:42:48 EST." <199802251642.LAA20515@jekyll.piermont.com> Date: Wed, 25 Feb 1998 16:22:28 -0500 From: Thomas Narten Perry, > I hate to say this, Scott, but a lifetime of seeing politicians in > action leads me to have no faith in either the statement that there > was no desire to bring the IETF to heel or that this will not be in > the cards in the future. Whether or not Ira can be trusted (say, for instance, because one believes he is evil because all politicians are evil) is beside the point. The fact remains he is an very important player in what is going on right now. One can either attempt to engage constructively, or take action that might well be perceived as openly hostile (and make things *much* worse). There are no guarantees with either approach, but rest assured that once the latter approach is taken, the first option is no longer an option. Looking at the big picture, which option would appear to have better odds of resulting in a positive outcome? > The man has created an enormous amount of chaos for our community, > sowing uncertainty and fear into a self governance process that was > largely working just fine. If this was by design, he's a deadly threat > both to the functioning of the internet and to our autonomy. If this > was by accident, he's dangerous simply because he doesn't understand > what he is doing and has great power to cause destruction without even > realizing it. Either way, I do not see any reason for faith or trust > in the man. Fine. You don't trust the man. However, it does not follow that attempts at constructive engagement should be abandoned. Thomas From owner-ietf-outbound.10 Wed Feb 25 17:10:18 1998 Delivery-Date: Wed, 25 Feb 1998 17:13:20 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id RAA10967 for ietf-outbound.10@ietf.org; Wed, 25 Feb 1998 17:10:03 -0500 (EST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA10856 for ; Wed, 25 Feb 1998 17:06:13 -0500 (EST) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id RAA25334; Wed, 25 Feb 1998 17:06:06 -0500 (EST) Message-Id: <199802252206.RAA25334@jekyll.piermont.com> To: Thomas Narten cc: perry@piermont.com, Scott Bradner , ietf@ns.ietf.org Subject: Re: from Ira Magaziner Re: IETF relationship to new IANA In-reply-to: Your message of "Wed, 25 Feb 1998 16:22:28 EST." <199802252122.QAA02784@cichlid.raleigh.ibm.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 25 Feb 1998 17:06:05 -0500 From: "Perry E. Metzger" Thomas Narten writes: > Whether or not Ira can be trusted (say, for instance, because one > believes he is evil because all politicians are evil) I'm not saying politicians are necessarily "evil". I'm saying it is foolish to believe anything they say. There is a difference. In the course of just this one battle, the various minions of the administration have changed their tune more often than a band playing a medley. One would be silly not to pay attention to experience. > is beside the point. The fact remains he is an very important player > in what is going on right now. One wonders why, of course. I mean, so far as I can tell there is no legal basis for his involvement. It appears that he's decided to insert himself. > One can either attempt to engage constructively, or take action that > might well be perceived as openly hostile (and make things *much* > worse). There are no guarantees with either approach, but rest > assured that once the latter approach is taken, the first option is > no longer an option. Looking at the big picture, which option would > appear to have better odds of resulting in a positive outcome? I am not merely being cynical when I say this: if you pretend you can negotiate as an equal with a high level politician, you have already lost everything. You believe this is "constructive engagement". From my perspective, this is "pretending you are even remotely in their league". They'll chew you up and swallow you before breakfast and never even notice they've done it. Attempting "constructive engagement" basically means surrender. None of us is capable of negotiating effectively with these people, and we are utterly fooling ourselves if we believe we are. We're TECHIES. These are people that have survived for their entire working lives in a shark pool. Natural selection has placed the guys who can live in that world on top. These are people as skilled at manipulating people as we are at writing C code. We can't deal with these people on their own terms -- we cannot win that game. We have to deal with them on *our terms*. The major chance we have is that we do not *have* to negotiate with them. I'm not suggesting hostility. I'm suggesting carefuly and calmly explaining "thank you, but no thank you. We prefer to decide the future of the way we assign protocol numbers or standards or anything else we deal with on our own, by our own peculiar methods. We've been self-governing for decades, and we are happiest that way, and until such time as someone presents us with a court order, we'll just stick to what we know." If Ira Magaziner wants to dictate our governance, let him pay his fee, show up at an IETF meeting, and talk in a POISSON meeting just like anyone else. That's an environment where we understand the rules. > > The man has created an enormous amount of chaos for our community, > > sowing uncertainty and fear into a self governance process that was > > largely working just fine. If this was by design, he's a deadly threat > > both to the functioning of the internet and to our autonomy. If this > > was by accident, he's dangerous simply because he doesn't understand > > what he is doing and has great power to cause destruction without even > > realizing it. Either way, I do not see any reason for faith or trust > > in the man. > > Fine. You don't trust the man. However, it does not follow that > attempts at constructive engagement should be abandoned. What would "constructive engagement" consist of? We're a legally constituted entity. He has no legal basis to dictate to us. If a government agent came up to your home and told you that henceforth he was running your family, would you say "well, lets negotiate this" or would you say "could you please show me your legal authority here?" If we "constructively engage", it will be a matter of years before federal appointees run the IAB and IESG (can't have that chaotic NOMCOM running things -- after all, they aren't controlled by the white house) and decide who can and can't do what in the IETF. May I remind people that we do not believe in voting or kings? That is not the IETF way. Perry From owner-ietf-outbound.10 Wed Feb 25 19:35:09 1998 Delivery-Date: Wed, 25 Feb 1998 19:36:47 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id TAA14819 for ietf-outbound.10@ietf.org; Wed, 25 Feb 1998 19:35:03 -0500 (EST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id TAA14766 for ; Wed, 25 Feb 1998 19:31:01 -0500 (EST) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Feb 25 19:26:07 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Wed Feb 25 19:28:33 EST 1998 Received: from smb.research.att.com (volvo.research.att.com [135.207.23.62]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id TAA00798; Wed, 25 Feb 1998 19:28:10 -0500 (EST) Message-Id: <3.0.3.32.19980225230320.009a23b0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 25 Feb 1998 23:03:20 +0000 To: perry@piermont.com From: "Steven M. Bellovin" Subject: Re: from Ira Magaziner Re: IETF relationship to new IANA Cc: Thomas Narten , perry@piermont.com, Scott Bradner , ietf@ns.ietf.org In-Reply-To: <199802252206.RAA25334@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >One wonders why, of course. I mean, so far as I can tell there is no >legal basis for his involvement. It appears that he's decided to >insert himself. Your other points notwithstanding, there is indeed a very clear and compelling reason for White House involvement -- the NSI contract. NSI is operating .COM under a contract from NSF. This contract expires March 31. And NSF has previously shown that they can assign that duty to whomever they please -- SRI was the previous operator. IANA is also government-funded. *Something* has to be decided; retaining the status quo is also a decision. The situation today is far more complex, of course, not least because very many people care about who runs .COM and what other TLDs there are. Furthermore, since there is disagreement *among several executive-branch agencies* about what to do, it's not only reasonable, it's proper for the White House to get involved. Clearly, there are limits to what Magaziner and the White House can do. There is absolutely no basis whatsoever for them to assert any degree of control, influence, etc., over the IETF, the IAB, the IESG, or ISOC. That very specifically means that RFC editing will remain under the IETF's control. Numeric parameter assignment is, too, except as we delegate it. The IAB statement indicated that we wish to continue letting IANA do this, even the new IANA. Now, we can disagree -- as you have -- with the wisdom of having any part in the new structure. But as best I can tell -- and this is based on what I've heard from various IETF folks who met with Magaziner and/or contacted him since the GP came out -- this much is entirely our decision. Magaziner is not mandating it, because -- as you've pointed out -- he can't. Speaking for myself and not the IAB, --Steve Bellovin From owner-ietf-outbound.10 Wed Feb 25 19:35:09 1998 Delivery-Date: Wed, 25 Feb 1998 19:36:47 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id TAA14819 for ietf-outbound.10@ietf.org; Wed, 25 Feb 1998 19:35:03 -0500 (EST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id TAA14766 for ; Wed, 25 Feb 1998 19:31:01 -0500 (EST) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Feb 25 19:26:07 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Wed Feb 25 19:28:33 EST 1998 Received: from smb.research.att.com (volvo.research.att.com [135.207.23.62]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id TAA00798; Wed, 25 Feb 1998 19:28:10 -0500 (EST) Message-Id: <3.0.3.32.19980225230320.009a23b0@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 25 Feb 1998 23:03:20 +0000 To: perry@piermont.com From: "Steven M. Bellovin" Subject: Re: from Ira Magaziner Re: IETF relationship to new IANA Cc: Thomas Narten , perry@piermont.com, Scott Bradner , ietf@ns.ietf.org In-Reply-To: <199802252206.RAA25334@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >One wonders why, of course. I mean, so far as I can tell there is no >legal basis for his involvement. It appears that he's decided to >insert himself. Your other points notwithstanding, there is indeed a very clear and compelling reason for White House involvement -- the NSI contract. NSI is operating .COM under a contract from NSF. This contract expires March 31. And NSF has previously shown that they can assign that duty to whomever they please -- SRI was the previous operator. IANA is also government-funded. *Something* has to be decided; retaining the status quo is also a decision. The situation today is far more complex, of course, not least because very many people care about who runs .COM and what other TLDs there are. Furthermore, since there is disagreement *among several executive-branch agencies* about what to do, it's not only reasonable, it's proper for the White House to get involved. Clearly, there are limits to what Magaziner and the White House can do. There is absolutely no basis whatsoever for them to assert any degree of control, influence, etc., over the IETF, the IAB, the IESG, or ISOC. That very specifically means that RFC editing will remain under the IETF's control. Numeric parameter assignment is, too, except as we delegate it. The IAB statement indicated that we wish to continue letting IANA do this, even the new IANA. Now, we can disagree -- as you have -- with the wisdom of having any part in the new structure. But as best I can tell -- and this is based on what I've heard from various IETF folks who met with Magaziner and/or contacted him since the GP came out -- this much is entirely our decision. Magaziner is not mandating it, because -- as you've pointed out -- he can't. Speaking for myself and not the IAB, --Steve Bellovin From owner-ietf-outbound.10 Wed Mar 4 11:50:57 1998 Delivery-Date: Wed, 04 Mar 1998 11:54:05 -0500 Return-Path: owner-ietf-outbound.10 Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA10593 for ietf-outbound.10@ietf.org; Wed, 4 Mar 1998 11:50:02 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA10352 for ; Wed, 4 Mar 1998 11:42:36 -0500 (EST) Received: from bcarsfba.ca.nortel.com by mailgate.nortel.ca; Wed, 4 Mar 1998 11:39:45 -0500 Received: from bmery1f6.bnr.ca (actually bmery1f6.ca.nortel.com) by bcarsfba.ca.nortel.com; Wed, 4 Mar 1998 11:38:33 -0500 Received: from bftzh114.ca.nortel.com by bmery1f6.bnr.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id GJGYYHS4; Wed, 4 Mar 1998 11:39:11 -0500 Sender: "Marcus Leech" Message-ID: <34FD8387.D8FD0503@nt.com> Date: Wed, 04 Mar 1998 11:38:31 -0500 From: "Marcus Leech" Organization: Nortel Technology, Messaging and Security Infrastructure X-Mailer: Mozilla 4.04 [en] (X11; U; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: perry@piermont.com, ietf@ns.ietf.org Subject: Re: Last Call: Anti-Spam Requirements on an SMTP MTA to BCP References: <199803041600.LAA08470@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Perry E. Metzger wrote: > > Jacob Palme writes: > > We started implementing anti-spam features which check the > > correctness of the domains of senders of incoming messages a few > > weeks ago. This did reduce the amount of spamming temporarily, but it > > is growing again, obviously the spammers have found ways to work > > around such measures. > > True enough, but this has a very salutory effect. > > It means that anyone spamming now has to steal someone's domain name > -- that is, to commit a kind of fraud. That generally means there is > someone who can sue them for damages, which is happening more and more > often (and which usually succeeds). We're starting to implement inbound spam filtering based on content "signature", rather than just headers. Even filtering on headers will reduce our inbound spam by about 70%. Each of the spam packages has a distinct "fingerprint". The fingerprints corresponding to the "STEALTH" e-mail spam software constitute about 50% or more of our inbound spam. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From smb@research.att.com Sun Mar 8 17:19:58 1998 Delivery-Date: Sun, 08 Mar 1998 17:19:59 -0500 Return-Path: smb@research.att.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA05998 for ; Sun, 8 Mar 1998 17:19:35 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA00971 for ; Sun, 8 Mar 1998 17:22:10 -0500 (EST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id RAA05995; Sun, 8 Mar 1998 17:19:07 -0500 (EST) Received: from research.att.com ([135.207.30.100]) by rumor; Sun Mar 8 17:15:59 EST 1998 Received: from hermes.research.att.com ([135.207.16.38]) by research-clone; Sun Mar 8 17:17:56 EST 1998 Received: from smb.research.att.com (smb-home.research.att.com [135.205.55.9]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id RAA07597; Sun, 8 Mar 1998 17:17:41 -0500 (EST) Received: from smb.research.att.com (smb@localhost) by smb.research.att.com (8.8.5/8.8.5) with ESMTP id RAA14963; Sun, 8 Mar 1998 17:17:26 -0500 (EST) Message-Id: <199803082217.RAA14963@smb.research.att.com> From: Steve Bellovin To: iab@ns.ietf.org, iesg@ns.ietf.org cc: rja@inet.org, fred@cisco.com, bellovin@acm.org, blakley@vnet.ibm.com, mab@research.att.com, brian@hursley.ibm.com, jte@cert.org, galvin@commerce.net, howes@netscape.com, Erik.Huizer@sec.nl, charlie_kaufman@iris.com, kent@bbn.com, paul@mci.net, mleech@nortel.ca, perry@piermont.com, moore@cs.utk.edu, rgm@htt-consult.com, jgm@cmu.edu, narten@raleigh.ibm.com, radia.perlman@sun.com, jwr@ideal.jf.intel.com, allyn@eng.sun.com, jis@mit.edu, tytso@mit.edu Subject: security architecture workshop RFC Date: Sun, 08 Mar 1998 17:17:06 -0500 Sender: smb@research.att.com Enclosed below is the penultimate draft. I've made changes corresponding to most of the (very few) comments I received. The only thing it may pay to hold off on is the final issuance of the IPsec/ISAKMP RFCs -- any thoughts? ----- Network Working Group Steven M. Bellovin Internet Draft AT&T Labs Research Expiration Date: May 1998 March 1998 Report of the IAB Security Architecture Workshop draft-iab-secwks-report-01.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. 3. Motivations On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. The ultimate goal was to design a security architecture for the Internet. More concretely, we wished to understand what security tools and protocols exist or are being developed, where each is useful, and where we are missing adequate security tools. Furthermore, we wanted to provide useful guidance to Bellovin [Page 1] Internet Draft draft-iab-secwks-report-01.txt March 1998 protocol designers. That is, if we wish to eliminate the phrase ``security issues are not discussed in this memo'' from future RFCs, we must provide guidance on acceptable analyses. There were twenty-four attendees (their names are listed in Appendix A). Perhaps not surprisingly for such a group, the overwhelming majority used some form of cryptography when connecting back to their home site from the meeting room. But the situation on the rest of the Internet is not nearly as good; few people use encryption, even when they should. The problem is that the rate of attacks is increasing. Apart from the usual few elite hackers -- the ones who find the new holes -- there are many canned exploit scripts around. (``Click here to attack this system.'') Furthermore, the attackers have gotten smarter; rather than going after random university machines, more and more are targeting the Internet infrastructure, such as routers, high-level name servers, and the like. The problem is compounded by organizational laziness. Users and system administrators want ``magic security'' -- they want whatever they do to be secure, regardless of whether or not it is, or even can be. 4. General Philosophy We concluded that in general, end-to-end security is better. Thus, one should use something like PGP or S/MIME for email, rather than relying on an IPsec layer. In general, relying on the security of the infrastructure is a bad idea; it, too, is under attack. Even firewall-protected intranets can be subverted. At best, the infrastructure should provide availability; it is the responsibility of individual protocols not to make unreasonable demands on the infrastructure during an attack. 5. IETF Structure Our security problem is compounded by the IETF's inherent structure (or, in some cases, the lack thereof). By intent, we are a volunteer organization. Who should do the security work? The other protocol designers? Often, they have neither the time nor the interest nor the training to do it. Security area members? What if they are not interested in some subject area, or lack the time themselves? We cannot order them to serve. To the extent that the IETF does have management, it is embodied in Bellovin [Page 2] Internet Draft draft-iab-secwks-report-01.txt March 1998 the working group charters. These are in essence contracts between the IESG and a working group, spelling out what is to be done and on what schedule. Can the IESG unilaterally impose new requirements on existing working groups? What if security cannot be added on without substantial changes to the fundamental structure of a protocol that has been reworked over several years? Finally, there is a perception problem: that IPsec will somehow solve the security problem. It won't; indeed, it can't. IPsec provides excellent protection of packets in transit. But it's hard to deploy on individual hosts, does not protect objects that may be retransmitted (i.e., email messages), does not address authorization issues, cannot block against excess resource consumption, etc. 6. Documents to be Written Collectively, we decided on several documents that need to be written: Taxonomy of Attacks In order to defend a protocol against attacks, one must, of course, know the kinds of attacks that are possible. While the specifics differ from protocol to protocol, a number of general categories can be constructed. Implementation Hints and Pitfalls Even if a protocol is sound, a host running it can be vulnerable if the protocol is implemented improperly. A variety of common errors can and do subvert the best designs. Firewall Issues Firewalls are both a common defense and a much-reviled wart on the Internet. Regardless, they are unlikely to go away any time soon. They have both strengths and weaknesses that must be considered when deploying them. Furthermore, some protocols have characteristics that are unnecessarily firewall-hostile; such practices should be avoided. Workshop Report This document. Bellovin [Page 3] Internet Draft draft-iab-secwks-report-01.txt March 1998 7. Working Group Charters The actual text in the working group charter is likely to be something fairly simple, like Protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases. The actual charter text represents a policy enjoined and enforced by the IESG, and may change from time to time and from charter to charter. However, it essentially references and asks for text in documents conforming to the following, which may be very appropriate to include in the RFC. 8. Guidelines on writing Security Considerations in an RFC A "threat" is, by definition, a vulnerability available to a motivated and capable adversary. CERT advisories are quite predictable given a knowledge of the target of the threat; they therefore represent an existence proof, but not a threat analysis. The point is to determine what attacks are possible ("capabilities" of a potential attacker) and formulate a defense against the attacks, or convincingly argue that the attack is not realistic in some environment and restrict use of the protocol to that environment. Recommended guidelines: All RFCs - MUST meaningfully address security in the protocol or procedure it specifies. It MUST consider that it is giving its data to "the enemy" and asking it to be delivered to its friends and used in the manner it intended. Consideration MUST be given to the ramifications of the inherent danger of the situation. - MUST do "due diligence" to list the threats to which the protocol is vulnerable. Use of legal term does not imply legal liability, but rather the level of responsibility expected to be applied to the analysis. This discussion might occur throughout the document or in the Security Considerations section; if it occurs throughout, it MUST be summarized and referenced in the Security Considerations section. - MUST discuss which of those threats are * Ameliorated by protocol mechanisms (example: SYN attack is ameliorated by clever code that drops sessions randomly when under SYN attack) Bellovin [Page 4] Internet Draft draft-iab-secwks-report-01.txt March 1998 * Ameliorated by reliance on external mechanisms (example: TCP data confidentiality provided by IPSEC ESP) * Irrelevant ("In most cases, MIBs are not themselves security risks; If SNMP Security is operating as intended, the use of a MIB to change the configuration of a system is a tool, not a threat. For a threat analysis of SNMP Security, see RFC ZZZZ.") * Not addressed by the protocol; results in applicability statement. ("This protocol should not be used in an environment subject to this attack") 9. Core Security Mechanisms A variety of security mechanisms exist today. Not all are well- designed; not all are suitable for all purposes. The members of the workshop designated a number of protocols as ``core''. Such protocols should be used preferentially, if one of them has properties that match the needs of your protocol. The following were designated as core: IPsec [RFC 1825] is the basic host-to-host security mechanism. It is appropriate for use any time address-based protection would have been used, including with such programs as rsh and rlogin. If and when platforms support user-based keying, this scope may be expanded. One particular technique used by IPsec, HMAC [RFC 2104], is more generally useful. If cryptographic authentication but not secrecy is needed, and IPsec is not applicable, HMAC should be used. ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation protocol for IPsec. As such, it should be deployed when IPsec is used. With the appropriate ``domain of interpretation'' document, it should be used to negotiate pairwise keys for other protocols. DNSsec [RFC 2065] is not only crucial for protecting the DNS -- cache contamination is the easiest way to launch active attacks -- it's also needed in many situations when IPsec is used. Security/Multipart [RFC 1847] is the preferred way to add secured sections to MIME-encapsulated email. Signed keys in the DNS. There is, as noted, widespread agreement that DNS records themselves must be protected. There was less Bellovin [Page 5] Internet Draft draft-iab-secwks-report-01.txt March 1998 agreement that the key records should be signed themselves, making them in effect certificates. Still, this is one promising avenue for Internet certificates. X.509v3 is the other obvious choice for a certificate infrastructure. Again, though, there was no strong consensus on this point. TLS [TLS draft] was seen by some as the preferred choice for transport-layer security, though there was no consensus on this point. TLS is less intrusive to the operating system than IPsec; additionally, it is easier to provide fine-grained protection this way. Some protocols were designated as ``useful but not core''. These were insufficiently general, too new, or were substantially duplicative of core protocols. These include AFT/SOCKS, RADIUS, firewalls, GSS-API, PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey, IPsec API, SASL, and CRAM/CHAP. Obviously, entries on this list may move in either direction. A few protocols were considered ``not useful''. Primarily, these are ones that have failed to catch on, even though they've been available for some time. These include PEM [RFC 1421, 1422, 1423, 1424] and MOSS [RFC 1848]. (The phrase "not useful" does not imply that they are incorrect, or are lacking in important information. However, they do not describe protocols that we are currently encouraging the use of.) One security mechanism was deemed to be unacceptable: plaintext passwords. That is, no protocol that relies on passwords sent over unencrypted channels is acceptable. 10. Missing Pieces Participants in the workshop identified three significant missing pieces: object security, secure email, and route security. Object security refers to protection for individual data objects, independent of transport. We have one such already -- Secure DNS -- but we need a me general scheme. MIME is a candidate object framework, in part because it is the core of the two most widely used and deployed applications: the web and email. However, securing email has been problematic and the web is not that far in front. Bellovin [Page 6] Internet Draft draft-iab-secwks-report-01.txt March 1998 Secure email is a critical need and has been for some time. Two attempts to standardize secure email protocols (PEM and MOSS) have failed to be accepted by the community, while a third protocol (PGP) has become a de facto standard around the world. A fourth protocol, an industry standard (S/MIME), has been gaining popularity. Both of these latter of entered the Internet standards process. Route security has recently become a critical need. The sophistication of the attackers is on the rise and the availability of attacking toolkits has increased the number of sophisticated attacks. This task is especially complex because the requirement for maximum performance conflicts with the goal of adding security, which usurps resources that would otherwise enhance the performance of the router. 11. Security Considerations Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are. 12. Acknowledgments This RFC is largely based on the minutes compiled by Thomas Narten, whose work in turn was partly based on notes by Erik Huizer, John Richardson, and Bob Blakley. 13. References [RFC 1825] Security Architecture for the Internet Protocol. R. Atkinson. August 1995. [RFC 2104] HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. [ISAKMP drafts] [RFC 2065] Domain Name System Security Extensions. D. Eastlake, 3rd, C. Kaufman. January 1997. [RFC 1847] Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker & N. Bellovin [Page 7] Internet Draft draft-iab-secwks-report-01.txt March 1998 Freed. October 1995. [TLS draft] [RFC 1421] Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. J. Linn. February 1993. [RFC 1422] Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. S. Kent. February 1993. [RFC 1423] Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. D. Balenson. February 1993. [RFC 1424] Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. B. Kaliski. February 1993. [RFC 1848] MIME Object Security Services. S. Crocker, N. Freed, J. Galvin & S. Murphy. October 1995. Appendix A. Attendees Ran Atkinson rja@inet.org Fred Baker fred@cisco.com Steve Bellovin bellovin@acm.org Bob Blakley blakley@vnet.ibm.com Matt Blaze mab@research.att.com Brian Carpenter brian@hursley.ibm.com Jim Ellis jte@cert.org James Galvin galvin@commerce.net Tim Howes howes@netscape.com Erik Huizer Erik.Huizer@sec.nl Charlie Kaufman charlie_kaufman@iris.com Steve Kent kent@bbn.com Paul Krumviede paul@mci.net Marcus Leech mleech@nortel.ca Perry Metzger perry@piermont.com Keith Moore moore@cs.utk.edu Robert Moskowitz rgm3@chrysler.com John Myers jgm@CMU.EDU Thomas Narten narten@raleigh.ibm.com Radia Perlman radia.perlman@sun.com John Richardson jwr@ibeam.jf.intel.com Allyn Romanow allyn@Eng.Sun.COM Bellovin [Page 8] Internet Draft draft-iab-secwks-report-01.txt March 1998 Jeff Schiller jis@mit.edu Ted T'So tytso@mit.edu Appendix B. Author Information Steven M. Bellovin AT&T Labs Research 180 Park Avenue Florham Park, NJ 07932 USA Phone: (973) 360-8656 email: bellovin@acm.org Bellovin [Page 9] From brian@hursley.ibm.com Mon Mar 9 08:52:56 1998 Delivery-Date: Mon, 09 Mar 1998 08:52:57 -0500 Return-Path: brian@hursley.ibm.com Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA22629 for ; Mon, 9 Mar 1998 08:52:54 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA02076 for ; Mon, 9 Mar 1998 08:55:29 -0500 (EST) Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id IAA22624; Mon, 9 Mar 1998 08:52:50 -0500 (EST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15927; Mon, 9 Mar 1998 13:49:40 GMT Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA94846; Mon, 9 Mar 1998 13:49:32 GMT Message-Id: <3503F3F9.5D615D4@hursley.ibm.com> Date: Mon, 09 Mar 1998 13:51:53 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Steve Bellovin Cc: iab@ns.ietf.org, iesg@ns.ietf.org, rja@inet.org, fred@cisco.com, bellovin@acm.org, blakley@vnet.ibm.com, mab@research.att.com, jte@cert.org, galvin@commerce.net, howes@netscape.com, Erik.Huizer@sec.nl, charlie_kaufman@iris.com, kent@bbn.com, paul@mci.net, mleech@nortel.ca, perry@piermont.com, moore@cs.utk.edu, rgm@htt-consult.com, jgm@cmu.edu, narten@raleigh.ibm.com, radia.perlman@sun.com, jwr@ideal.jf.intel.com, allyn@eng.sun.com, jis@mit.edu, tytso@mit.edu Subject: Re: security architecture workshop RFC References: <199803082217.RAA14963@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IMHO it's fine. Get it out as an I-D and request RFC publication conditional on the RFC numbers being allocated for the IPSEC/ISAKMP stuff - the RFC Ed can handle that. Brian From cclark Fri Mar 20 16:00:09 1998 Delivery-Date: Fri, 20 Mar 1998 16:09:39 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id QAA29665 for ietf-outbound.10@ietf.org; Fri, 20 Mar 1998 16:00:03 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.UCSC.EDU [128.114.129.45]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA28879 for ; Fri, 20 Mar 1998 15:43:19 -0500 (EST) Received: from krazy.UCSC.EDU (krazy.UCSC.EDU [128.114.129.44]) by cats.ucsc.edu (8.8.5/8.8.4.cats-athena) with SMTP id MAA20409; Fri, 20 Mar 1998 12:43:23 -0800 (PST) From: Mark Boolootian Received: by krazy.UCSC.EDU (8.6.13/4.7) id MAA08876; Fri, 20 Mar 1998 12:43:15 -0800 Message-Id: <199803202043.MAA08876@krazy.UCSC.EDU> Subject: Re: is there an aggregate RFC tar file somewhere? To: perry@piermont.com Date: Fri, 20 Mar 1998 12:43:14 -0800 (PST) Cc: ietf@ns.ietf.org In-Reply-To: <199803201955.OAA08795@jekyll.piermont.com> from "Perry E. Metzger" at Mar 20, 98 02:55:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text >I also maintain a local RFC repository. I use "mirror" to do it (via >ftp). Works very nicely. Of course. Thanks I retract the request. From cclark Sat Mar 21 21:00:12 1998 Delivery-Date: Sat, 21 Mar 1998 21:01:19 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id VAA02368 for ietf-outbound.10@ietf.org; Sat, 21 Mar 1998 21:00:02 -0500 (EST) Received: from rip.psg.com (root@rip.psg.com [147.28.0.39]) by ns.ietf.org (8.8.7/8.8.7a) with SMTP id UAA02237 for ; Sat, 21 Mar 1998 20:49:30 -0500 (EST) Received: by rip.psg.com id m0yGZt8-0007zWC; Sat, 21 Mar 98 17:49 PST (Smail3.1.29.1#1) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 21 Mar 1998 17:49:24 -0800 (PST) To: perry@PIERMONT.COM Cc: ietf@ns.ietf.org Subject: Re: Let's Summarize References: <199803220107.UAA12022@jekyll.piermont.com> Message-ID: <13588.28002.212082.955356@rip.psg.com> > Unfortunately, I don't want to put Johnny, or Steve Bellovin, or Karl > Auerbach, or any one of the dozens of other people I think are smart > into my kill file, so I have to put up with reading their REPLIES to > Jim's rantings. * ^To:.*(Jim Fleming|Bob Allisat|Eugene Kashpureff) * ^Cc:.*(Jim Fleming|Bob Allisat|Eugene Kashpureff) Works pretty well except when folk clean the header. randy From cclark Tue Mar 31 10:00:15 1998 Delivery-Date: Tue, 31 Mar 1998 10:05:37 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id KAA00394 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 10:00:03 -0500 (EST) Received: from mail0.tor.acc.ca (mail0.tor.acc.ca [204.92.54.110]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA00317 for ; Tue, 31 Mar 1998 09:52:34 -0500 (EST) Received: from [142.154.136.3] (ppp-034.m4-1.cgy.ican.net [142.154.136.34]) by mail0.tor.acc.ca (8.8.8/8.8.8) with ESMTP id JAA29903; Tue, 31 Mar 1998 09:51:59 -0500 (EST) Date: Tue, 31 Mar 1998 09:51:59 -0500 (EST) X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: <199803311402.JAA15841@jekyll.piermont.com> References: Your message of "Tue, 31 Mar 1998 02:30:45 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@piermont.com From: "Howard C. Berkowitz" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ietf@ns.ietf.org At 9:02 -0500 3/31/98, Perry E. Metzger wrote: >"Howard C. Berkowitz" writes: >> I may have missed a writeup that already exists, > >Such as the documents we are discussing, yes.... You mean obscure things like draft-ietf-ipsec-arch-sec-04.txt? I recognize there are other working documents, but this is Last Call for a specific one, which doesn't appear to reference certain issues. Issues about which prominent members of the community are extremely vocal -- well, more vocal than usual :-) > >> but the two quotes below add to my feeling there needs to be a clear >> architectural discussion of: > >The issues you raise are discussed in the documents. Please read them. > >Perry Yes: such as >. This document does not address all aspects of IPsec > architecture. Subsequent documents will address additional > architectural details of a more advanced nature, e.g., use of IPsec > in NAT environments and more complete support for IP multicast NAT and routing are more my areas than the satellite issues. Nevertheles, in an architecture document, I would like more meat that a "To be addressed." I'd like an initial statement of problems in the interctions between NAT/firewalls and IPsec, with emphasis on vulnerability. Sandy Murphy;s BGP Security Analysis is the sort of document I have in mind. The architecture document doesn't need to contain this, but there should be a reasonable pointer, which I don't see. The emphasis is on the protocols and protocol entities rather than their deployment. Howar From cclark Tue Mar 31 14:10:30 1998 Delivery-Date: Tue, 31 Mar 1998 14:16:25 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id OAA05156 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 14:10:01 -0500 (EST) Received: from mail0.tor.acc.ca (mail0.tor.acc.ca [204.92.54.110]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA05097 for ; Tue, 31 Mar 1998 14:07:50 -0500 (EST) Received: from [142.154.136.3] (ppp-042.m4-1.cgy.ican.net [142.154.136.42]) by mail0.tor.acc.ca (8.8.8/8.8.8) with ESMTP id OAA08646; Tue, 31 Mar 1998 14:07:09 -0500 (EST) Date: Tue, 31 Mar 1998 14:07:09 -0500 (EST) X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: <199803311502.KAA16223@jekyll.piermont.com> References: Your message of "Tue, 31 Mar 1998 09:51:59 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@piermont.com From: "Howard C. Berkowitz" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: ietf@ns.ietf.org At 10:02 -0500 3/31/98, Perry E. Metzger wrote: >"Howard C. Berkowitz" writes: >> At 9:02 -0500 3/31/98, Perry E. Metzger wrote: >> >"Howard C. Berkowitz" writes: >> >> I may have missed a writeup that already exists, >> > >> >Such as the documents we are discussing, yes.... >> >> You mean obscure things like draft-ietf-ipsec-arch-sec-04.txt? > >If you think that internet drafts are obscure, might I respectfully >suggest that you familiarize yourself with the mechanism, as it is a >basic requirement for functioning in the IETF environment? Apparently the sarcasm mode was missed. I am quite familiar with the process, and have authored and coauthored both current I-D's and RFCs. > >> I recognize there are other working documents, but this is Last Call >> for a specific one, > >If you are not aware of the other ipsec docs, all of which are named >consistantly, with draft-ietf-ipsec prefixes, to make them easy to >find in the internet drafts directory, might I suggest that you >familiarize yourself with them? That is not my point. This is a last call for a specific document, an architectural one. As I read the current version of that document, it does not reference some ongoing work, nor does it deal with certain issues raised in the last call discussion and elsewhere. The purpose of an architectural document is to map requirements into system components. I am aware that the directory you cite include discussions of the cryptographic protocols of primary interest to code implementers. Detailed knowledge of all of these is not critical when analyzing architecture. Reading knowledge of other IPSEC documents is relevant; a professional knows that some selectivity is in order. Unfortunately, my initial phrasing of my concerns in a more subtle manner apparently went over Mr. Metzger's head, and he chose the opportunity to patronize. I shall not engage in further childish discussion as whether I do or do not understand the IETF process to which I have contributed. Stating things more succinctly, I think the architecture document, specifically, does not either discuss proxy vs. end-to-end functions in the context of risk analysis, nor does it reference a document that does. There have been strong arguments about the interactions of IPsec and various proxy and proxy-like functions, including NAT, satellite spoofing, firewalls, etc. Perhaps some guidance from the IESG or IAB is in order, clarifying how the IETF will build consensus on the interaction of these security and infrastructure technologies. Specific commentary on the effect of widespread IPsec deployment on the demand for globally routable IPv4 space, under various scenarios of IPsec tunneling, should be considered. From cclark Tue Mar 31 14:50:07 1998 Delivery-Date: Tue, 31 Mar 1998 14:57:44 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id OAA06128 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 14:50:01 -0500 (EST) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id OAA05902 for ; Tue, 31 Mar 1998 14:46:37 -0500 (EST) Received: by janus.tor.securecomputing.com id <11652>; Tue, 31 Mar 1998 14:47:36 -0500 Message-Id: <98Mar31.144736est.11652@janus.tor.securecomputing.com> To: "Howard C. Berkowitz" cc: perry@piermont.com, ietf@ns.ietf.org Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard References: Your message of "Tue, 31 Mar 1998 09:51:59 EST." In-reply-to: hcb's message of "Tue, 31 Mar 1998 14:07:09 -0500". From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 31 Mar 1998 14:46:25 -0500 In message , "Howard C. Berkowitz" writes: > > Stating things more succinctly, I think the architecture document, > specifically, does not either discuss proxy vs. end-to-end functions in the > context of risk analysis, nor does it reference a document that does. > There have been strong arguments about the interactions of IPsec and > various proxy and proxy-like functions, including NAT, satellite spoofing, > firewalls, etc. Perhaps some guidance from the IESG or IAB is in order, > clarifying how the IETF will build consensus on the interaction of these > security and infrastructure technologies. Specific commentary on the effect > of widespread IPsec deployment on the demand for globally routable IPv4 > space, under various scenarios of IPsec tunneling, should be considered. None of these were in the Charter for the IPsec working group. This was deliberate; they're hard problems. Many of them are (or will be) in the Charter for the IPsecond working group, and I'm sure we'd love to have you participate in those discussions. There's precedent for splitting work like this, after all. We're up to RIPv2, SNMPv3, and BGPv4 right now, after all. -- Harald From cclark Tue Mar 31 15:10:13 1998 Delivery-Date: Tue, 31 Mar 1998 15:12:52 -0500 Return-Path: cclark Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id PAA06838 for ietf-outbound.10@ietf.org; Tue, 31 Mar 1998 15:10:02 -0500 (EST) Received: from mail0.tor.acc.ca (mail0.tor.acc.ca [204.92.54.110]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06479 for ; Tue, 31 Mar 1998 15:06:44 -0500 (EST) Received: from [142.154.136.3] (ppp-042.m4-1.cgy.ican.net [142.154.136.42]) by mail0.tor.acc.ca (8.8.8/8.8.8) with ESMTP id PAA22073; Tue, 31 Mar 1998 15:06:17 -0500 (EST) Date: Tue, 31 Mar 1998 15:06:17 -0500 (EST) X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: <98Mar31.144736est.11652@janus.tor.securecomputing.com> References: hcb's message of "Tue, 31 Mar 1998 14:07:09 -0500". Your message of "Tue, 31 Mar 1998 09:51:59 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "C. Harald Koch" From: "Howard C. Berkowitz" Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: perry@piermont.com, ietf@ns.ietf.org At 14:46 -0500 3/31/98, C. Harald Koch wrote: >In message , "Howard C. Berkowitz" >writes: >> >> Stating things more succinctly, I think the architecture document, >> specifically, does not either discuss proxy vs. end-to-end functions in the >> context of risk analysis, nor does it reference a document that does. >> There have been strong arguments about the interactions of IPsec and >> various proxy and proxy-like functions, including NAT, satellite spoofing, >> firewalls, etc. Perhaps some guidance from the IESG or IAB is in order, >> clarifying how the IETF will build consensus on the interaction of these >> security and infrastructure technologies. Specific commentary on the effect >> of widespread IPsec deployment on the demand for globally routable IPv4 >> space, under various scenarios of IPsec tunneling, should be considered. > >None of these were in the Charter for the IPsec working group. This was >deliberate; they're hard problems. I can get along with stating thing in those terms, although I would suggest that this conscious limiting doesn't come across in the architecture document. Again, my concern is that the enterprise network architect realistically is not going to go back to the charter. If things are consciously out of scope, a pointer to that would help enormously in getting deployed. Your points are well taken and my comments are meant to be supportive of the overall effort. I do in fact monitor IPsec drafts, but, I think realistically as do many others, I actively comment in only a certain subset of the WGs. If something reaches last call, and especially if it is impacting other areas of work, it seems appropriate to me to try to build consensus and clarity. That is the point of my comments, I want the work to be used. I don't want to see things happen such as people coming into NAT, etc., and saying "you can't do this because it breaks IPsec." > >Many of them are (or will be) in the Charter for the IPsecond working group, >and I'm sure we'd love to have you participate in those discussions. I'd be happy to do so, especially within my area of specialization, which is more routing and addressing. I fully recognize the need to limit the scope of work in order to get things done. > > >There's precedent for splitting work like this, after all. We're up to RIPv2, >SNMPv3, and BGPv4 right now, after all. Given the IPsecond effort is being formed, does it make sense to identify the current document as IPsec V1? Seriously, I think that would help among nonspecialists. Your comments are valid, and I hope mine are taken in the constructive way they are meant. I've killfiled Mr. Metzger. Howard From adm Wed Apr 1 02:00:38 1998 Delivery-Date: Wed, 01 Apr 1998 02:01:26 -0500 Return-Path: adm Return-Path: Received: by ietf.org.ietf.org (SMI-8.6/SMI-SVR4) id CAA02517; Wed, 1 Apr 1998 02:00:03 -0500 Received: from homebase.htt-consult.com (homebase.htt-consult.com [208.235.169.130]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id BAA01050 for ; Wed, 1 Apr 1998 01:32:47 -0500 (EST) Received: from ietf-11-175 ([198.94.11.175]) by homebase.htt-consult.com (Netscape Mail Server v2.02) with SMTP id AAC317; Wed, 1 Apr 1998 01:32:39 -0500 Message-Id: <3.0.5.32.19980331145815.00a1d2b0@homebase.htt-consult.com> X-Sender: rgm-ietf@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 31 Mar 1998 14:58:15 -0800 To: perry@piermont.com, "Howard C. Berkowitz" From: Robert Moskowitz Subject: Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard Cc: Stephen Kent , ietf@ns.ietf.org In-Reply-To: <199803311959.OAA17555@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-length: 842 At 02:59 PM 3/31/98 -0500, Perry E. Metzger wrote: > >Because "trusted NAT", meaning "share your encryption keys with your >routers" is like "military intelligence" or "congressional >oversight", perhaps? In some cases, there can be a trusted NAT. This is a system setup for this task only, not a bunch of other firewallish and NAT stuff to limit risks. In many of these cases, there might be an ESP gw-gw tunnel and within it a NULL-ESP end-end transport within. But ESP transport cannot be NATed, as the TCP checksum is in the ESP frame and the IP addresses are not. So it would have to be NULL-ESP end-end tunnel. BTW, this is valuable to protect your connection over the internet, but to know who the actual end party is in an inter-enterprise environment (where it is unwise to trust IP addresses as gw-gw tends to result with). From cclark Thu Apr 30 03:30:15 1998 Delivery-Date: Thu, 30 Apr 1998 03:38:01 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id DAA19010 for ietf-outbound.10@ietf.org; Thu, 30 Apr 1998 03:30:03 -0400 (EDT) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA18896 for ; Thu, 30 Apr 1998 03:24:33 -0400 (EDT) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id CAA23281; Thu, 30 Apr 1998 02:21:59 -0500 (CDT) Received: from dal-tx43-32.ix.netcom.com(207.221.94.160) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma023274; Thu Apr 30 02:21:35 1998 Message-ID: <3547C2F1.3A6F64FF@ix.netcom.com> Date: Thu, 30 Apr 1998 01:16:51 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: "DOMAIN-POLICY@LISTS.INTERNIC.NET" CC: "Global TLD's discuss" , Gordon Cook , IETF ORG , Ira Magaziner , Jim Dixon , Jim Fleming , John Broomfield , Jon Postel , Kent Crispin , Michael Dillon , PAB_Mail_List , Paul A Vixie , Perry Metzger , POC_MAILING_LIST , Richard Sexton , "Roeland M.J. Meyer" , Simon Higgs , Tony Rutkowski , Don Heath Subject: MoU's CORE and it's leaders intend to fragment The DNS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, News update: The MoU/CORE DNS plan push threatens to fragment DNS structure in face of Green Paper's wide expectance. See story http://www.techweb.com/se/directlink.cgi?WIR1997110501 Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com From cclark Thu Apr 30 08:50:10 1998 Delivery-Date: Thu, 30 Apr 1998 09:08:29 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id IAA22693 for ietf-outbound.10@ietf.org; Thu, 30 Apr 1998 08:50:02 -0400 (EDT) Received: from email3.etsi.fr (email3.etsi.fr [195.221.129.24]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA22211 for ; Thu, 30 Apr 1998 08:41:39 -0400 (EDT) Received: by EMAIL3 with Internet Mail Service (5.0.1460.8) id ; Thu, 30 Apr 1998 14:38:36 +0200 Message-ID: From: Roberto Gaetano To: DOMAIN-POLICY@LISTS.INTERNIC.NET, "'Jeff Williams'" Cc: "Global TLD's discuss" , Gordon Cook , IETF ORG , Ira Magaziner , Jim Dixon , Jim Fleming , John Broomfield , Jon Postel , Kent Crispin , Michael Dillon , PAB_Mail_List , Paul A Vixie , Perry Metzger , POC_MAILING_LIST , Richard Sexton , "Roeland M.J. Meyer" , Simon Higgs , Tony Rutkowski , Don Heath Subject: RE: MoU's CORE and it's leaders intend to fragment The DNS Date: Thu, 30 Apr 1998 14:38:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Hi, Jeff. You wrote: > News update: > > The MoU/CORE DNS plan push threatens to fragment DNS structure in face of > Green Paper's wide expectance. > See story > http://www.techweb.com/se/directlink.cgi?WIR1997110501 > What is the interest today of this press release, that is almost six months old? Regards Roberto From cclark Mon May 11 15:40:24 1998 Delivery-Date: Mon, 11 May 1998 15:49:27 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA25931 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 15:40:02 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25859 for ; Mon, 11 May 1998 15:35:24 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id MAA10351; Mon, 11 May 1998 12:35:14 -0700 (PDT) Message-Id: <199805111935.MAA10351@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 12:34:29 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805111541.LAA25301@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:41 AM 5/11/98 -0400, Perry E. Metzger wrote: >You know, somehow I've been surviving with SMTP for this for years, >and it works well for myself and my users. I really am not certain why >this sudden critical need has arrived. Perhaps the hundreds of >thousands of people using SMTP for this purpose are mistaken and only >*think* it works. The need is not "sudden". The topic was under discussion for quite awhile, as in a couple/few years. The need HAS been made MORE urgent by the onset of spam problems and the need to treat submission markedly different from relaying. You know, the Arpanet went 10 years without a special posting protocol for mail, instead using an adjunct command for file transfer. But the net grows and demands change. So we created SMTP. It's now time to create a distinct posting service and to create it as simply as possible. Instantiating SMTP on a separate port and with some very explicit statements about the strictures at the server, distinguishing relay processing from submission processing, is the easiest way for us to accomplish this. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Mon May 11 17:31:07 1998 Delivery-Date: Mon, 11 May 1998 17:41:23 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA27555 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 17:30:02 -0400 (EDT) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.18]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27477 for ; Mon, 11 May 1998 17:23:50 -0400 (EDT) Received: from lautrec.esys.ca (lautrec.esys.ca [198.161.92.11]) by rembrandt.esys.ca (2.0.2/8.8.8) with SMTP id PAA25795; Mon, 11 May 1998 15:20:55 -0600 Date: Mon, 11 May 1998 15:20:54 -0600 (MDT) From: Lyndon Nerenberg To: Dave Crocker cc: perry@piermont.com, Jack De Winter , ietf-submit@IMC.ORG, ietf@ietf.org Subject: Re: Last Call: SMTP Message Submission to Proposed Standard In-Reply-To: <199805111935.MAA10351@baygate.bayarea.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It's now time to create a distinct posting service and to create it as > simply as possible. Instantiating SMTP on a separate port and with some > very explicit statements about the strictures at the server, distinguishing > relay processing from submission processing, is the easiest way for us to > accomplish this. The problem with SUBMIT (according to the latest draft I reviewed) is that AUTH is optional. Unless SUBMIT *requires* authenticated message injection it isn't going to do anything to solve the spam problem. In fact, it makes it worse: SUBMIT servers, by definition, *must* support relay. I still contend that the existing SMTP, coupled with AUTH, and including the SUBMIT header processing extensions described in the draft, will work just fine one the existing port. In the course of identifying yourself to the SMTP server (via AUTH), the SMTP server is able to determine (through those authentication credentials) whether the authenticated entity is entitled to "submit" messages. (E.g., if the "submit" bit is lit up in the credentials for the authentication entity, the server allows relaying and enables the SUBMIT header processing functionality.) As a bonus side effect, it ensures the rapid deployment of SMTP AUTH. --lyndon From cclark Mon May 11 20:10:19 1998 Delivery-Date: Mon, 11 May 1998 20:18:43 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id UAA29069 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 20:10:02 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA29023 for ; Mon, 11 May 1998 20:03:16 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id RAA02042; Mon, 11 May 1998 17:02:46 -0700 (PDT) Message-Id: <199805120002.RAA02042@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 16:59:51 -0700 To: Lyndon Nerenberg From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, Jack De Winter , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: References: <199805111935.MAA10351@baygate.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 03:20 PM 5/11/98 -0600, Lyndon Nerenberg wrote: >> It's now time to create a distinct posting service and to create it as >> simply as possible. Instantiating SMTP on a separate port and with some > >The problem with SUBMIT (according to the latest draft I reviewed) is that >AUTH is optional. Unless SUBMIT *requires* authenticated message injection That is correct. No one said that the current spec solves the spamming problem. Rather, the concern is to separate submission from relaying, so that a range of differential services can be considered and developed. Use of submission-time authentication is just one -- albeit obvious and important -- concern. >I still contend that the existing SMTP, coupled with AUTH, and including >the SUBMIT header processing extensions described in the draft, will work >just fine one the existing port. In the course of identifying yourself to It is always possible to multiplex two different services together. Multiplexing mail over the file transfer protocol worked fine for ten years. Analysis of any single item can easily lead one to be convinced that we do not need to separate things. The problem is that the "flavour" of submission has come far enough to be distinguishable from relaying and should therefore be separated explicitly. If you have two different ports, you can have two different code bases, or you can have one code-base and let it run on both ports. If you have one port, there is no choice. You must use a single code base. Code which has massive numbers of tests like (if relay then...; else ...) sprinkled freely throughout greatly increases the complexity and bugginess of code. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Mon May 11 21:10:14 1998 Delivery-Date: Mon, 11 May 1998 21:18:43 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id VAA29353 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 21:10:01 -0400 (EDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29316 for ; Mon, 11 May 1998 21:02:53 -0400 (EDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id VAA25941; Mon, 11 May 1998 21:02:41 -0400 (EDT) Message-Id: <199805120102.VAA25941@jekyll.piermont.com> To: Dave Crocker cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org Subject: Re: Last Call: SMTP Message Submission to Proposed Standard In-reply-to: Your message of "Mon, 11 May 1998 12:34:29 PDT." <199805111935.MAA10351@baygate.bayarea.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 May 1998 21:02:41 -0400 From: "Perry E. Metzger" Dave Crocker writes: > The need HAS been made MORE urgent by the onset of spam problems and the > need to treat submission markedly different from relaying. I've heard the anti-spam arguments and I just don't belive them. Forging in-transit mail is trivial, and implementing anti-relaying in SMTP servers is also trivial. (My site has anti-relaying -- I have for some time now. It was about twenty lines of code added to my MTA. No big deal.) > It's now time to create a distinct posting service and to create it as > simply as possible. I'm not arguing that no posting service has a reasonable use. I'm just arguing that the claim that we have a sudden crisis that mandates that we take immediate action to push forward this particular protocol sounded bogus. Perry From cclark Mon May 11 21:30:12 1998 Delivery-Date: Mon, 11 May 1998 21:38:11 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id VAA29478 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 21:30:02 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29452 for ; Mon, 11 May 1998 21:29:18 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id SAA25110; Mon, 11 May 1998 18:28:46 -0700 (PDT) Message-Id: <199805120128.SAA25110@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 18:23:50 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120102.VAA25941@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:02 PM 5/11/98 -0400, Perry E. Metzger wrote: > >Dave Crocker writes: >> The need HAS been made MORE urgent by the onset of spam problems and the >> need to treat submission markedly different from relaying. > >I've heard the anti-spam arguments and I just don't belive doesn't matter what you or I believe. what matters is that already 50% of the smtp sites on the net have turned off posting from outside their local net. This is killing mobile users. In any event, I was using that as an indication of heightened concern about treating submission as an independent service. >anti-relaying -- I have for some time now. It was about twenty lines >of code added to my MTA. No big deal.) Well, you're lucky that spam control is so easy for you. It is proving rather more problematic for many other sites. >I'm not arguing that no posting service has a reasonable use. I'm just >arguing that the claim that we have a sudden crisis that mandates that >we take immediate action to push forward this particular protocol The topic lay fallow for about a year. The current urgency has reminded us to finish the work that was already underway. Finish means finish, not start over. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Mon May 11 21:30:12 1998 Delivery-Date: Mon, 11 May 1998 21:38:11 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id VAA29478 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 21:30:02 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29452 for ; Mon, 11 May 1998 21:29:18 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id SAA25110; Mon, 11 May 1998 18:28:46 -0700 (PDT) Message-Id: <199805120128.SAA25110@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 18:23:50 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120102.VAA25941@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:02 PM 5/11/98 -0400, Perry E. Metzger wrote: > >Dave Crocker writes: >> The need HAS been made MORE urgent by the onset of spam problems and the >> need to treat submission markedly different from relaying. > >I've heard the anti-spam arguments and I just don't belive doesn't matter what you or I believe. what matters is that already 50% of the smtp sites on the net have turned off posting from outside their local net. This is killing mobile users. In any event, I was using that as an indication of heightened concern about treating submission as an independent service. >anti-relaying -- I have for some time now. It was about twenty lines >of code added to my MTA. No big deal.) Well, you're lucky that spam control is so easy for you. It is proving rather more problematic for many other sites. >I'm not arguing that no posting service has a reasonable use. I'm just >arguing that the claim that we have a sudden crisis that mandates that >we take immediate action to push forward this particular protocol The topic lay fallow for about a year. The current urgency has reminded us to finish the work that was already underway. Finish means finish, not start over. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Mon May 11 22:00:07 1998 Delivery-Date: Mon, 11 May 1998 22:08:08 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id WAA29761 for ietf-outbound.10@ietf.org; Mon, 11 May 1998 22:00:01 -0400 (EDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29722 for ; Mon, 11 May 1998 21:58:24 -0400 (EDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id VAA26092; Mon, 11 May 1998 21:58:17 -0400 (EDT) Message-Id: <199805120158.VAA26092@jekyll.piermont.com> To: Dave Crocker cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org Subject: Re: Last Call: SMTP Message Submission to Proposed Standard In-reply-to: Your message of "Mon, 11 May 1998 18:23:50 PDT." <199805120128.SAA25110@baygate.bayarea.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 May 1998 21:58:17 -0400 From: "Perry E. Metzger" Dave Crocker writes: > At 09:02 PM 5/11/98 -0400, Perry E. Metzger wrote: > > > >Dave Crocker writes: > >> The need HAS been made MORE urgent by the onset of spam problems and the > >> need to treat submission markedly different from relaying. > > > >I've heard the anti-spam arguments and I just don't belive > > doesn't matter what you or I believe. what matters is that already 50% of > the smtp sites on the net have turned off posting from outside their local > net. A very good idea. > This is killing mobile users. Hardly. I'm a mobile user, and I have no trouble uploading mail, AND I have relaying off. > >anti-relaying -- I have for some time now. It was about twenty lines > >of code added to my MTA. No big deal.) > > Well, you're lucky that spam control is so easy for you. It is proving > rather more problematic for many other sites. That is far more a question of sites not actively updating or maintaining their software than anything else, from what I can tell. If they were running recent versions of most software they could get anti-relaying capability. It certainly doesn't appear to be a protocol problem -- the existing protocols work just fine. Perry From cclark Tue May 12 00:50:11 1998 Delivery-Date: Tue, 12 May 1998 00:56:00 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id AAA07702 for ietf-outbound.10@ietf.org; Tue, 12 May 1998 00:50:01 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07677 for ; Tue, 12 May 1998 00:47:10 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id VAA08291; Mon, 11 May 1998 21:46:41 -0700 (PDT) Message-Id: <199805120446.VAA08291@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 21:46:39 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120158.VAA26092@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:58 PM 5/11/98 -0400, Perry E. Metzger wrote: >> This is killing mobile users. > >Hardly. I'm a mobile user, and I have no trouble uploading mail, AND I >have relaying off. It's always dangerous to take the practises of a highly skilled technician and apply it to the general user population. There are no mechanisms currently available off the shelf which are well integrated and sufficient, for doing authentication-based SMTP relaying. If your pop server happens to support non-standard access to smtp and the user is running eudora, then they can use this mechanism, if they happen to know the name of the undocumented .ini parameter to create by hand. This is not reasonable to impose on or expect from the general population. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Tue May 12 00:50:11 1998 Delivery-Date: Tue, 12 May 1998 00:56:00 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id AAA07702 for ietf-outbound.10@ietf.org; Tue, 12 May 1998 00:50:01 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07677 for ; Tue, 12 May 1998 00:47:10 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.5/8.8.5) id VAA08291; Mon, 11 May 1998 21:46:41 -0700 (PDT) Message-Id: <199805120446.VAA08291@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Mon, 11 May 1998 21:46:39 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, "Jack De Winter" , ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120158.VAA26092@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:58 PM 5/11/98 -0400, Perry E. Metzger wrote: >> This is killing mobile users. > >Hardly. I'm a mobile user, and I have no trouble uploading mail, AND I >have relaying off. It's always dangerous to take the practises of a highly skilled technician and apply it to the general user population. There are no mechanisms currently available off the shelf which are well integrated and sufficient, for doing authentication-based SMTP relaying. If your pop server happens to support non-standard access to smtp and the user is running eudora, then they can use this mechanism, if they happen to know the name of the undocumented .ini parameter to create by hand. This is not reasonable to impose on or expect from the general population. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Wed May 13 11:20:13 1998 Delivery-Date: Wed, 13 May 1998 11:28:51 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA16017 for ietf-outbound.10@ietf.org; Wed, 13 May 1998 11:20:03 -0400 (EDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15791 for ; Wed, 13 May 1998 11:12:43 -0400 (EDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Wed, 13 May 1998 11:12:47 -0400 Message-Id: <3.0.1.32.19980513111251.009c4710@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 13 May 1998 11:12:51 -0400 To: Dave Crocker , perry@piermont.com From: "Jack De Winter" Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120128.SAA25110@baygate.bayarea.net> References: <199805120102.VAA25941@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 06:23 PM 5/11/98 -0700, Dave Crocker wrote: >>I've heard the anti-spam arguments and I just don't belive > >doesn't matter what you or I believe. what matters is that already 50% of >the smtp sites on the net have turned off posting from outside their local >net. This is killing mobile users. > >In any event, I was using that as an indication of heightened concern about >treating submission as an independent service. Not a product plug, but our mail server actually has two different modes, authentication and unauthenticated. Depending on which you are, you will either be allowed to relay or not. This solves the mobile user problem (as that use can authenticate as soon as all of the services like SMTP support it, along with the clients) while maintaining the anti-relaying for those that dont authenticate with the server. As far as our customers think, this is a very happy medium, except for the fact that few SMTP clients use authentication at this time. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From cclark Wed May 13 11:20:13 1998 Delivery-Date: Wed, 13 May 1998 11:28:51 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA16017 for ietf-outbound.10@ietf.org; Wed, 13 May 1998 11:20:03 -0400 (EDT) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [207.164.71.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15791 for ; Wed, 13 May 1998 11:12:43 -0400 (EDT) Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca ([207.164.71.2],mail daemon,WBMAILNT V3.0); Wed, 13 May 1998 11:12:47 -0400 Message-Id: <3.0.1.32.19980513111251.009c4710@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 13 May 1998 11:12:51 -0400 To: Dave Crocker , perry@piermont.com From: "Jack De Winter" Subject: Re: Last Call: SMTP Message Submission to Proposed Standard Cc: perry@piermont.com, ietf-submit@IMC.ORG, ietf@ietf.org In-Reply-To: <199805120128.SAA25110@baygate.bayarea.net> References: <199805120102.VAA25941@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 06:23 PM 5/11/98 -0700, Dave Crocker wrote: >>I've heard the anti-spam arguments and I just don't belive > >doesn't matter what you or I believe. what matters is that already 50% of >the smtp sites on the net have turned off posting from outside their local >net. This is killing mobile users. > >In any event, I was using that as an indication of heightened concern about >treating submission as an independent service. Not a product plug, but our mail server actually has two different modes, authentication and unauthenticated. Depending on which you are, you will either be allowed to relay or not. This solves the mobile user problem (as that use can authenticate as soon as all of the services like SMTP support it, along with the clients) while maintaining the anti-relaying for those that dont authenticate with the server. As far as our customers think, this is a very happy medium, except for the fact that few SMTP clients use authentication at this time. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 884-4498 http://www.wildbear.on.ca/jacks/ From cclark Thu May 14 11:50:20 1998 Delivery-Date: Thu, 14 May 1998 11:58:47 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA14087 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 11:50:04 -0400 (EDT) Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13657 for ; Thu, 14 May 1998 11:40:38 -0400 (EDT) Received: from vucqpqlj (user-37kbmtg.dialup.mindspring.com [207.69.219.176]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id LAA29820; Thu, 14 May 1998 11:38:32 -0400 (EDT) Message-Id: <3.0.2.32.19980514113818.0069ba88@mindspring.com> X-Sender: iquest1@mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 14 May 1998 11:38:18 -0400 To: perry@piermont.com From: Jay Fenello Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] Cc: "Donald E. Eastlake 3rd" , IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET In-Reply-To: <199805141332.JAA06128@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" [with apologies to IETF members . . .] Hi Perry, It's nice to hear from you again! Based on your tone, it looks like I have hit a nerve ;-) Is there something in those missing archives that frightens you? Jay. At 09:32 AM 5/14/98 -0400, Perry E. Metzger wrote: > >I wonder if I should put up the archive of the tcpdump of Jay's >machines being used by Eugene Kashpureff to try to exploit bugs in >BIND to force my machines to resolve their fraudulent TLDs. > >Nah. That would only be resurrecting an episode we all want to >forget. After all, its best if the thugs look like upstanding >citizens. > >Is Eugene out of jail now, btw? I've stopped following the news carefully. > >Perry > >"Donald E. Eastlake 3rd" writes: >> On Tue, 12 May 1998, Jay Fenello wrote: >> >> > Date: Tue, 12 May 1998 13:02:48 -0400 >> > From: Jay Fenello >> > Subject: Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresenta >tion of Jeff williams's comments] >> > >> > ... >> > >> > If you are interested, there is semi-complete >> > summary of the email archives and the Postel >> > drafts at: >> > http://www.newdom.com/archive/ >> > >> > I used the term semi-complete, because there >> > is a mysterious gap in the historical record. >> > It appears that the entire IAHC email archives, >> > *and* the corresponding Newdom email archives >> > are missing :-( >> >> The IAHC mailing list archives are, not very suprisingly, on the IAHC site >> at . At 01:58 AM 5/14/98 -0400, Jay Fenello wrote: > >Hi Donald, > >Thanks for the update. > >Here's what remains missing . . . > > >Two significnt events are missing with the lost newdom@ar.com > >files: 1) Postel announcing formation of the IAHC committee > >and 2) community reaction to 1). > > > >Also minor things like when Shaw called GTE Federal Systems > >and was busted. > >Does anyone know where these archives can be found? > >Thanks, > >Jay. From cclark Thu May 14 12:10:18 1998 Delivery-Date: Thu, 14 May 1998 12:20:43 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA14729 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 12:10:03 -0400 (EDT) Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14632 for ; Thu, 14 May 1998 12:06:23 -0400 (EDT) Received: from vucqpqlj (user-37kbmtg.dialup.mindspring.com [207.69.219.176]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id MAA18602; Thu, 14 May 1998 12:05:08 -0400 (EDT) Message-Id: <3.0.2.32.19980514120455.0069d61c@mindspring.com> X-Sender: iquest1@mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 14 May 1998 12:04:55 -0400 To: perry@piermont.com From: Jay Fenello Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] Cc: "Donald E. Eastlake 3rd" , IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET In-Reply-To: <199805141515.LAA06365@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:15 AM 5/14/98 -0400, Perry E. Metzger wrote: > >Jay Fenello writes: >>Also minor things like when Shaw called GTE Federal Systems >>and was busted. Hi Perry, I was not the author of that, it was a non-attributed quote. The author was referring, however, to the *discovery* that Bob was the person responsible for ending GTE's use of the alternate roots, after he specifically requested that his identity be kept a secret. Why do you think Bob wanted to keep his identity a secret? Jay. >"was busted"? > >Shaw called GTE, and GTE removed your friend Eugene's crud from their >systems. He was not "busted", which is local parlance for >"arrested". It is true that people posted that Bob called them, which >was hardly something anyone was hiding. > >The only person that got arrested -- "busted" -- was your pal >Eugene. As I recall, one of the few reasons other people didn't get >arrested was that I thought it was a stupid idea. Perhaps I should >have been less charitable about my logging data. > >Perry > From cclark Thu May 14 12:30:17 1998 Delivery-Date: Thu, 14 May 1998 12:38:46 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA15487 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 12:30:03 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14817 for ; Thu, 14 May 1998 12:10:44 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.8/8.8.5) id JAA16492; Thu, 14 May 1998 09:06:11 -0700 (PDT) Message-Id: <199805141606.JAA16492@baygate.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Thu, 14 May 1998 08:38:10 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: FAQ: SMTP Message Submission to Proposed Standard Cc: Chris Newman , ietf@ietf.org, ietf-submit@IMC.ORG In-Reply-To: <199805141512.LAA06357@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:12 AM 5/14/98 -0400, Perry E. Metzger wrote: >> The email industry desperately needs an authenticated submission >> service. > >Given that relaying isn't authenticated, this strikes me as >unimportant. Remember that SMTP is not an end to end protocol but a This reaction is perhaps a good exemplar for what I suspect is the real problem in this debate, namely that IETF technical work has gotten much more specialized -- i.e., there are masses more of detail and context to each activity -- and those of us -- yes, I said us -- who like to dabble broadly often don't have quite enough background to get away with it. One might counter by saying that FAQ and other explanatory efforts need to be thorough, but that's really an impossible task, if carried to its logical extreme. The need for submission-time authentication is to create a basis for what is being called "first hop accountability", so that the service which injects the message into the mail relay system can be help responsible for allowing spam to be passed. In other words, authentication now has a variety of purposes, not just to permit the final recipient assurance of correct author labeling. I'm a large fan of end-to-end data object security, but this particular requirement does not need it. >> (2) Why have a separate submit port? >> >> Submit and relay are separate services. Submit needs to have more >> stringent validation of content, > >I dispute that. If you can forge a submission via forged messages to >the relay, then why will stringent validation on ingress help? Sources which allow forged mail will come to find that sites no longer accept mail from them. Or they will find serious legal repercussions for permitting spam to be injected. >> (4) Why doesn't security protocol X solve all the problems? >> >> MTA/MUA vendors have to sell products which work out of the box. That >> means they can't insist on the installation of custom TCP/IP stacks > >TLS requires no custom hacks. Its layered on top of TCP, and it is >standards track. Since when does the IETF require one and only one solution to be make into a standard? One of the other unfortunate aspects about this debate is that it has been focused on security and spam, rather than email functionality and architecture. It's fine that we've gone so long without a separate posting protocol, just as it was fine we went so long without a special relaying protocol. But the divergence between posting and relaying has been developing for a few years and it's now time to make it official. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Thu May 14 12:40:20 1998 Delivery-Date: Thu, 14 May 1998 12:47:39 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA15844 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 12:40:03 -0400 (EDT) Received: from ties.itu.ch (lindner@ties.itu.ch [156.106.192.33]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA15463 for ; Thu, 14 May 1998 12:29:41 -0400 (EDT) Received: (from lindner@localhost) by ties.itu.ch (8.9.0.Beta5/8.9.0.Beta5) id SAA20285; Thu, 14 May 1998 18:29:36 +0200 (MET DST) Message-ID: <19980514182935.I3680@ties.itu.ch> Date: Thu, 14 May 1998 18:29:35 +0200 From: Paul Lindner To: Jay Fenello , perry@piermont.com Cc: "Donald E. Eastlake 3rd" , IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] Mail-Followup-To: Jay Fenello , perry@piermont.com, "Donald E. Eastlake 3rd" , IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET References: <199805141332.JAA06128@jekyll.piermont.com> <3.0.2.32.19980514113818.0069ba88@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <3.0.2.32.19980514113818.0069ba88@mindspring.com>; from Jay Fenello on Thu, May 14, 1998 at 11:38:18AM -0400 Anyone who wants to relive this whole thing can see http://www.iahc.org/iahc-discuss/thrd10.html#02675 and read the subject IAHC-Gate. Also consult the date index for Mar 10, 1997. http://www.iahc.org/iahc-discuss/date27.html#02651 ...We now return you to your regularly unscheduled program.... On Thu, May 14, 1998 at 11:38:18AM -0400, Jay Fenello wrote: > > > [with apologies to IETF members . . .] > > Hi Perry, > > It's nice to hear from you again! > > Based on your tone, it looks like > I have hit a nerve ;-) > > Is there something in those missing > archives that frightens you? > > Jay. > > > At 09:32 AM 5/14/98 -0400, Perry E. Metzger wrote: > > > >I wonder if I should put up the archive of the tcpdump of Jay's > >machines being used by Eugene Kashpureff to try to exploit bugs in > >BIND to force my machines to resolve their fraudulent TLDs. > > > >Nah. That would only be resurrecting an episode we all want to > >forget. After all, its best if the thugs look like upstanding > >citizens. > > > >Is Eugene out of jail now, btw? I've stopped following the news carefully. > > > >Perry > > > >"Donald E. Eastlake 3rd" writes: > >> On Tue, 12 May 1998, Jay Fenello wrote: > >> > >> > Date: Tue, 12 May 1998 13:02:48 -0400 > >> > From: Jay Fenello > >> > Subject: Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresenta > >tion of Jeff williams's comments] > >> > > >> > ... > >> > > >> > If you are interested, there is semi-complete > >> > summary of the email archives and the Postel > >> > drafts at: > >> > http://www.newdom.com/archive/ > >> > > >> > I used the term semi-complete, because there > >> > is a mysterious gap in the historical record. > >> > It appears that the entire IAHC email archives, > >> > *and* the corresponding Newdom email archives > >> > are missing :-( > >> > >> The IAHC mailing list archives are, not very suprisingly, on the IAHC site > >> at . > > > At 01:58 AM 5/14/98 -0400, Jay Fenello wrote: > > > >Hi Donald, > > > >Thanks for the update. > > > >Here's what remains missing . . . > > > > >Two significnt events are missing with the lost newdom@ar.com > > >files: 1) Postel announcing formation of the IAHC committee > > >and 2) community reaction to 1). > > > > > >Also minor things like when Shaw called GTE Federal Systems > > >and was busted. > > > >Does anyone know where these archives can be found? > > > >Thanks, > > > >Jay. > > -- Paul Lindner International Telecommunication Union paul.lindner@itu.int Tel: +41 22 730-5587 Fax: +41 22 730 5337 From cclark Thu May 14 13:00:32 1998 Delivery-Date: Thu, 14 May 1998 13:08:48 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA16336 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 13:00:02 -0400 (EDT) Received: from baygate.bayarea.net (root@baygate.bayarea.net [204.71.212.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA16235 for ; Thu, 14 May 1998 12:56:30 -0400 (EDT) Received: (from dcrocker@localhost) by baygate.bayarea.net (8.8.8/8.8.5) id JAA00854; Thu, 14 May 1998 09:50:31 -0700 (PDT) Message-Id: <4.0.1.329.19980514092520.0115e880@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.329 (Beta) Date: Thu, 14 May 1998 09:53:45 -0700 To: perry@piermont.com From: Dave Crocker Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] Cc: IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET In-Reply-To: <199805141515.LAA06365@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:15 AM 5/14/98 -0400, Perry E. Metzger wrote: >systems. He was not "busted", which is local parlance for >"arrested". It is true that people posted that Bob called them, which >was hardly something anyone was hiding. Perry, you are forgetting that in Jay's world, one person's error becomes a conspiracy by other parties, if it serves Jay's interests. So the fact that the GTE person couldn't even remember what country the call was from -- just for grins, try to imagine hearing Bob's New Jersey accent and thinking that he's from Australia -- is not interpreted as flakiness on the part of that person, but instead a conspiracy by Bob to purport to be someone else. In general, it's worth noting that Jay likes to raise issues that have nothing to do with content and then hammer away. It's really nothing but classic campaign smear practises. The problem isn't so much that he stoops to the tactics, it's that anyone bothers to listen to him. d/ _________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 273 6464 www.brandenburg.com Sunnyvale, CA 94086 USA From cclark Thu May 14 13:20:10 1998 Delivery-Date: Thu, 14 May 1998 13:28:02 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA16823 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 13:20:03 -0400 (EDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA16636 for ; Thu, 14 May 1998 13:13:08 -0400 (EDT) Received: from elwood.innosoft.com ("port 63126"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IX0QAPJM46985DW4@INNOSOFT.COM> for ietf@ietf.org; Thu, 14 May 1998 10:12:05 PDT Date: Thu, 14 May 1998 10:13:36 -0700 (PDT) From: Chris Newman Subject: Re: FAQ: SMTP Message Submission to Proposed Standard In-reply-to: <199805141512.LAA06357@jekyll.piermont.com> To: "Perry E. Metzger" Cc: ietf@ietf.org, ietf-submit@IMC.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM On Thu, 14 May 1998, Perry E. Metzger wrote: > Given that relaying isn't authenticated, this strikes me as > unimportant. Remember that SMTP is not an end to end protocol but a > hop-to-hop protocol. This means that the only real security that can > be provided for it is object security, like S/MIME. > > Authentication of submission is nice, therefore, but not "critical". S/MIME (whenever the standards track version is completed) will authenticate the author of the content of the message to the user at the other end. It solves a different problem. Authenticated submission authenticates the submission of the content, headers and envelope of the message to the submission server. The submission server's authentication of the submittor is completely independent of the end-to-end S/MIME security problem. Like it or not, the owner of the submission server is partially responsible for what messages are sent out to the Internet (e.g., to cancel spammer accounts, fix serious protocol violations which kill remote servers, track down the sender of a message which threatens to kill the president, etc). Therefore it _is_ a requirement that the submission server be capable of authenticating the submittor. And this is critical. > > (2) Why have a separate submit port? > > > > Submit and relay are separate services. Submit needs to have more > > stringent validation of content, > > I dispute that. If you can forge a submission via forged messages to > the relay, then why will stringent validation on ingress help? Thanks to spam, all unauthenticated relays have to be adjusted so they only relay to approved machines (usually only local machines). That's necessary to prevent the major spam fanout abuses. Submission servers will relay the message anywhere assuming the user has appropriate authorization. And because a submission server only processes outgoing email, it can afford the time necessary to be much more picky about what it accepts. Because it's interactive, it has a chance to return diagnostics back to the user -- diagnostics which would be inappropriate on a relay action. But if the two services aren't separated, the combined submission/relay server can't do any validation which might slow or damage the normal flow of incoming email and it's restricted to diagnostics suitable for relay connections. > > (4) Why doesn't security protocol X solve all the problems? > TLS requires no custom hacks. Its layered on top of TCP, and it is > standards track. What are the standards track RFC numbers for TLS and the SMTP profile thereof? > > the purchase of certificates from Verisign before working. > > Not necessary, either. Are you sure about that? To interoperate with deployed clients, a server has to: (1) Support SSL as well as TLS (2) Use the RSA / RC4 cipher suite (and support 40-bit encryption keys) (3a) Purchase a certificate signed by one of the CAs that's built into all the clients in use. or (3b) Generate a self-signed certificate and manually reconfigure every client on site to accept that certificate (at some sites this can be done by telling users to say "OK" to the appropriate dialog box). (4) Generate an manage client certificates for all users. This has proved to be very hard in practice. It's hard to find a web server which actually uses client certs. Granted, this is a viable solution for some sites -- especially ones where the users are capable of setting up their own client certs, but it's not viable at most sites. And it's very hard for some MUA/MTA vendors for various reasons. So TLS is a useful tool at times, but by itself, it only solves the authenticated submission problem in a fraction of the real world cases. - Chris "Good security is hard. X.509 is harder." From cclark Thu May 14 14:10:13 1998 Delivery-Date: Thu, 14 May 1998 14:17:15 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA17895 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 14:10:03 -0400 (EDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17735 for ; Thu, 14 May 1998 14:01:33 -0400 (EDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA06593; Thu, 14 May 1998 14:00:13 -0400 (EDT) Message-Id: <199805141800.OAA06593@jekyll.piermont.com> To: Jay Fenello cc: perry@piermont.com, "Donald E. Eastlake 3rd" , IETF ORG Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] In-reply-to: Your message of "Thu, 14 May 1998 12:04:55 EDT." <3.0.2.32.19980514120455.0069d61c@mindspring.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 May 1998 14:00:13 -0400 From: "Perry E. Metzger" Jay Fenello writes: > The author was referring, however, to the *discovery* that > Bob was the person responsible for ending GTE's use of the > alternate roots, after he specifically requested that his > identity be kept a secret. > > Why do you think Bob wanted to keep his identity a secret? For those who actually care (about .05% of you), Jay is distorting the following incident: some low level guy at GTE put a couple of GTE's machines into Eugene's FraudNIC, er, AlterNIC, system. Bob called up GTE and said "hey, does your management know about this?" to which their management said "hell no! we didn't approve any such thing, and we're doing something about it immediately." Bob did nothing untoward -- not that anyone should give a damn at this point. I'm going to stop polluting the IETF list with this now -- Jay is about the last of the LoonyNIC crowd that isn't in my kill file, and perhaps I will change that soon. Perry From cclark Thu May 14 15:00:16 1998 Delivery-Date: Thu, 14 May 1998 15:08:07 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA18808 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 15:00:02 -0400 (EDT) Received: from camel8.mindspring.com (camel8.mindspring.com [207.69.200.58]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA18654 for ; Thu, 14 May 1998 14:51:25 -0400 (EDT) Received: from vucqpqlj (user-37kbmtg.dialup.mindspring.com [207.69.219.176]) by camel8.mindspring.com (8.8.5/8.8.5) with SMTP id OAA00313; Thu, 14 May 1998 14:51:23 -0400 (EDT) Message-Id: <3.0.2.32.19980514145109.006ecf58@mindspring.com> X-Sender: iquest1@mindspring.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Thu, 14 May 1998 14:51:09 -0400 To: perry@piermont.com From: Jay Fenello Subject: OFF TOPIC ==> Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] Cc: IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET, Ira_C._Magaziner@oa.eop.gov, bburr@ntia.doc.gov, dns@ntia.doc.gov In-Reply-To: <199805141753.NAA06577@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 01:53 PM 5/14/98 -0400, Perry E. Metzger wrote: > >Jay Fenello writes: >> Based on your tone, it looks like >> I have hit a nerve ;-) > >Who's hit a nerve for whom, Mr. Fenello? Nervous smiley there, >perhaps? > >I've got logs, Mr. Fenello, of your machines being used to launch an >attack on mine. You can't possibly be unaware of this. Eugene >Kashpureff was probably the major player in the incident in question, >but it appears you actively cooperated with him. > >As I said, I've never considered submitting them to the >authorities. My taste for bringing the law to bear in what I could >only describe as questions of decorum isn't very strong. However, as >long as we are talking about archives, and as long as you were going >to use inflamitory language, I thought I'd mention that there are all >sorts of archives out there, and that the statute of limitations has >yet to expire. Hi Perry, Thank you for showing the entire IETF community the tactics that you have been using since I joined the debate in January, 1997. It is one reason why I have named you one of the people most responsible for the divisions that now exist in the Internet community. What started out as a discussion about missing email archives (of which the Newdom discussions of the IAHC formation and the community response to it are *still* missing), you have resorted to the next strategy on your check list -- personal attacks. And unlike the email archives that *have* mysteriously vanished, the details of my relationship with Eugene are clearly available in the remaining email archives. I encourage everyone interested to review them at: http://www.newdom.com/archive/ I am proud of my involvement in this debate, and regardless of the outcome, I know that in some small way, I have helped to make the Internet a better place. Regards, Jay Fenello President, Iperdome, Inc. 404-250-3242 http://www.iperdome.com >> Is there something in those missing archives that frightens you? > >There are no "missing archives" of postings. > >What there has been, this entire time, is the problem that on the >internet, no one knows you're a dog -- or, put more directly, that >uninformed observers have difficulty knowing that Jeff Williams is, in >fact, a loon living in a residential hotel in Texas and is not the >"Director" of anything other than his own bath towels, that Eugene, as >much as he tried to make himself look like a reasonable guy, ended up >being jailed thanks to his thuggish behavior, that Jim Fleming is a >delusional guy who babbles about "Stargates" and the "IPv8" protocol, >which exists entirely in his own imagination, and who largely posts >calculated untruths about every topic he discusses, etc., etc. > >Practically the only person here who I actually see as a legitimately >tragic figure is Karl Denninger, who is a reasonably honest man and >who appears to have legitimately believed in what he was doing, and >tried to do it with some honesty. The rest of you, however, all have >about as much personal credibility as the Unibomber. > >For quite some time here, we've all had our inboxes saturated with >crud by people who, in a previous era, would have been reduced to >handing out mimeographs on the streetcorner about the CIA controlling >their brains with microwaves. The lessons for the future of politics >should be taken. > >However, in spite of your capacities for drivel production, you have >nothing to frighten *ANYONE* here. What you can do, however, is post >day and night until people surrender and put you in their kill files. > >Perry > From cclark Thu May 14 17:11:32 1998 Delivery-Date: Thu, 14 May 1998 17:19:08 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA21093 for ietf-outbound.10@ietf.org; Thu, 14 May 1998 17:10:02 -0400 (EDT) Received: from wlv.iipo.gtegsc.com (0@WLV.IIPO.GTEGSC.COM [199.107.242.11]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA21067 for ; Thu, 14 May 1998 17:09:43 -0400 (EDT) Received: from MCC.IIPO.GTEGSC.COM (MCC.IIPO.GTEGSC.COM [199.107.242.254]) by wlv.iipo.gtegsc.com (8.8.5/8.8.5) with SMTP id OAA07641; Thu, 14 May 1998 14:04:41 -0700 (PDT) Date: Thu, 14 May 1998 14:04:40 -0700 (PDT) From: Merton Campbell Crockett To: Jay Fenello cc: perry@piermont.com, "Donald E. Eastlake 3rd" , IETF ORG , DOMAIN-POLICY@LISTS.INTERNIC.NET Subject: Re: IAHC archive [was Re: Comments on gTLD-MOU Leadership [was: Bob shaws misrepresentation of Jeff williams's comments]] In-Reply-To: <3.0.2.32.19980514120455.0069d61c@mindspring.com> Message-ID: Sender: mcc@WLV.IIPO.GTEGSC.COM MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I realize that GTE is a much simpler reference than GTE Governemt Systems Corporation, Federal Systems Division. This was the only organization that was, briefly, involved with alternate roots. GTE Corporation, GTE Internet Network Solutions, and GTE Internetworking were not involved. The individual responsible for configuring one of the DNS servers for the alternate roots was advised by me to discontinue the support as it had impacts at other GTE Government Systems' sites. I am not aware of any others who may, or may not, have contacted the individual with regard to the alternate roots. Merton Campbell Crockett Domain Administrator GTE Government Systems On Thu, 14 May 1998, Jay Fenello wrote: } At 11:15 AM 5/14/98 -0400, Perry E. Metzger wrote: } > } >Jay Fenello writes: } >>Also minor things like when Shaw called GTE Federal Systems } >>and was busted. } } } Hi Perry, } } I was not the author of that, it was a non-attributed quote. } } The author was referring, however, to the *discovery* that } Bob was the person responsible for ending GTE's use of the } alternate roots, after he specifically requested that his } identity be kept a secret. } } Why do you think Bob wanted to keep his identity a secret? } } Jay. } } } >"was busted"? } > } >Shaw called GTE, and GTE removed your friend Eugene's crud from their } >systems. He was not "busted", which is local parlance for } >"arrested". It is true that people posted that Bob called them, which } >was hardly something anyone was hiding. } > } >The only person that got arrested -- "busted" -- was your pal } >Eugene. As I recall, one of the few reasons other people didn't get } >arrested was that I thought it was a stupid idea. Perhaps I should } >have been less charitable about my logging data. } > } >Perry } > } } From cclark Thu May 21 22:10:14 1998 Delivery-Date: Thu, 21 May 1998 22:19:44 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id WAA18445 for ietf-outbound.10@ietf.org; Thu, 21 May 1998 22:10:03 -0400 (EDT) Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA18391 for ; Thu, 21 May 1998 22:02:34 -0400 (EDT) Received: (from smap@localhost) by dfw-ix14.ix.netcom.com (8.8.4/8.8.4) id VAA27648; Thu, 21 May 1998 21:00:09 -0500 (CDT) Received: from dal-tx49-19.ix.netcom.com(198.211.45.147) by dfw-ix14.ix.netcom.com via smap (V1.3) id rma027598; Thu May 21 20:59:56 1998 Message-ID: <35647801.F6291C91@ix.netcom.com> Date: Thu, 21 May 1998 19:52:50 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: ARIN list CC: Arin Council , "Global TLD's discuss" , "David R. Conrad" , IETF ORG , Ira Magaziner , Jim Dixon , Jon Postel , Justice department , Kim Hubbard , Liz Williams , Paul A Vixie , Perry Metzger Subject: [Fwd: The authors thank Jeff Williams...] X-Priority: 2 (High) Content-Type: multipart/mixed; boundary="------------B907EBFB1BD810C25EF05B5C" This is a multi-part message in MIME format. --------------B907EBFB1BD810C25EF05B5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Form a post sent to me. Hope you enjoy. regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com --------------B907EBFB1BD810C25EF05B5C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from lists.internic.net (lists.internic.net [198.41.0.15]) by ixmail5.ix.netcom.com (8.8.7-s-4/8.8.7/(NETCOM v1.01)) with ESMTP id QAA25996; ; Thu, 21 May 1998 16:59:02 -0700 (PDT) Received: from lists (lists.internic.net [198.41.0.15]) by lists.internic.net (8.8.7/8.8.4) with ESMTP id TAA13434; Thu, 21 May 1998 19:51:58 -0400 (EDT) Received: from LISTS.INTERNIC.NET by LISTS.INTERNIC.NET (LISTSERV-TCP/IP release 1.8c) with spool id 8108172 for DOMAIN-POLICY@LISTS.INTERNIC.NET; Thu, 21 May 1998 19:51:55 -0400 Received: from doorstep.unety.net (ns.unety.net [207.32.128.1]) by lists.internic.net (8.8.7/8.8.4) with SMTP id TAA13421 for ; Thu, 21 May 1998 19:51:53 -0400 (EDT) Received: from webster.unir.net ([207.32.159.5]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id SAA25104; Thu, 21 May 1998 18:50:16 -0500 Received: by webster.unir.net with Microsoft Mail id <01BD84E8.85973400@webster.unir.net>; Thu, 21 May 1998 18:44:44 -0500 Encoding: 23 TEXT Message-ID: <01BD84E8.85973400@webster.unir.net> Date: Thu, 21 May 1998 18:44:43 -0500 Reply-To: Jim Fleming Sender: Owner-Domain-Policy From: Jim Fleming Subject: The authors thank Jeff Williams... X-To: APPLe X-cc: "BBURR@ntia.doc.gov" , "Ira_C._Magaziner@oa.eop.gov" , "toru@tokyonet.ad.jp" To: DOMAIN-POLICY@LISTS.INTERNIC.NET @@@@@ http://www.cli.org/paper4.htm The New 'Civic Virtue' of the Internet David R. Johnson Co-Director, Cyberspace Law Institute David G. Post Co-Director, Cyberspace Law Institute ... "The authors thank Jeff Williams for his superb assistance in developing and implementing the computer-based complex systems discussed herein." ... "and participants at the Aspen Institute's "Internet as Platform" conference" ... @@@@@@@@@@@@@@@@@@@@ - Jim Fleming Unir Corporation - http://www.unir.net/IPv8 IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM -- DOMAIN-POLICY administrivia should be sent to To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP" --------------B907EBFB1BD810C25EF05B5C-- From cclark Wed May 27 19:51:32 1998 Delivery-Date: Wed, 27 May 1998 20:53:14 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id TAA11726 for ietf-outbound.10@ietf.org; Wed, 27 May 1998 19:50:01 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11682 for ; Wed, 27 May 1998 19:45:58 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id SAA13995 for ; Wed, 27 May 1998 18:46:00 -0500 (CDT) Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender xdat11@email.mot.com ) Received: from s-il06ad.corp.mot.com (s-il06ad.corp.mot.com [199.2.152.200]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id SAB21114 for ; Wed, 27 May 1998 18:45:58 -0500 (CDT) Received: by s-il06ad.corp.mot.com with Internet Mail Service (5.5.1960.3) id ; Wed, 27 May 1998 18:45:57 -0500 Message-ID: <8105C9E5A0DDD111AC6100805FFE65A242CF@s-il06ad.corp.mot.com> From: Geurs Dave-xdat11 To: "'Jeff Williams'" , ARIN list Cc: Arin Council , "Global TLD's discuss" , "David R. Conrad" , IETF ORG , Ira Magaziner , Jim Dixon , Jon Postel , Justice department , Kim Hubbard , Liz Williams , Paul A Vixie , Perry Metzger Subject: RE: [Fwd: The authors thank Jeff Williams...] Date: Wed, 27 May 1998 18:45:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Jeff, Are you saying or implying that the Jeff Williams mentioned in the article is you? Inquiring minds want to know. Regards, Dave > -----Original Message----- > From: Jeff Williams [SMTP:jwkckid1@IX.NETCOM.COM] > Sent: Thursday, May 21, 1998 1:53 PM > To: ARIN list > Cc: Arin Council; Global TLD's discuss; David R. Conrad; IETF ORG; > Ira Magaziner; Jim Dixon; Jon Postel; Justice department; Kim Hubbard; > Liz Williams; Paul A Vixie; Perry Metzger > Subject: [Fwd: The authors thank Jeff Williams...] > > All, > > Form a post sent to me. Hope you enjoy. > > regards, > > -- > Jeffrey A. Williams > DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > << Message: The authors thank Jeff Williams... >> > =================================== @@@@@ http://www.cli.org/paper4.htm The New 'Civic Virtue' of the Internet David R. Johnson Co-Director, Cyberspace Law Institute David G. Post Co-Director, Cyberspace Law Institute ... "The authors thank Jeff Williams for his superb assistance in developing and implementing the computer-based complex systems discussed herein." ... "and participants at the Aspen Institute's "Internet as Platform" conference" ... @@@@@@@@@@@@@@@@@@@@ - Jim Fleming Unir Corporation - http://www.unir.net/IPv8 IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM -- DOMAIN-POLICY administrivia should be sent to To unsubscribe send a message with only one line "SIGNOFF DOMAIN-POLICY" For more help regarding Listserv commands send the one line "HELP" > From cclark Fri Jun 12 13:20:08 1998 Delivery-Date: Fri, 12 Jun 1998 13:34:33 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA20799 for ietf-outbound.10@ietf.org; Fri, 12 Jun 1998 13:20:02 -0400 (EDT) Received: from wlv.iipo.gtegsc.com (0@WLV.IIPO.GTEGSC.COM [199.107.242.11]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20519 for ; Fri, 12 Jun 1998 13:09:18 -0400 (EDT) Received: from SPIELZEUG.TO.GSC.GTE.COM (SPIELZEUG.TO.GSC.GTE.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.5/8.8.5) with SMTP id KAA27798; Fri, 12 Jun 1998 10:06:06 -0700 (PDT) Date: Fri, 12 Jun 1998 10:05:51 -0700 (PDT) From: Merton Campbell Crockett To: "Perry E. Metzger" cc: "Roeland M.J. Meyer" , domain-policy@open-rsc.org, com-priv@PSI.COM, telecomreg@relay.doit.wisc.edu, ietf@ietf.org, CYBERTELECOM-L@LISTSERV.AOL.COM, DOMAIN-POLICY@lists.internic.net Subject: Re: Why do Don Heath and ISOC Risk Destruction of Internet's Chances for Self Regulation? In-Reply-To: <199806121603.MAA03275@jekyll.piermont.com> Message-ID: X-X-Sender: mcc@wlv.IIPO.GTEGSC.COM MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My apologies for using your message but what's with all of the vitriole that's gushing forth on this list? Admittedly the Internet can be regarded as a playground. But, does it necessitate behaving like small children arguing around the swing set? I'm surprised someone hasn't used HTML to show that they can yell the loudest by using bold-face 72 point caps. Merton Campbell Crockett GTE Government Systems, ESD/ISO On Fri, 12 Jun 1998, Perry E. Metzger wrote: } } "Roeland M.J. Meyer" writes: } > According to my history, Don Heath was the originator of the current } > situation of limited TLD in the first place. Don Heath clearly never did, } > and still doesn't, want the TLD space opened up to ANY degree. } } I'm fascinated by where you get your data from. Obviously not from } actually being familiar with the situation -- the current DNS } structure way predates Don Heath's involvement with the } internet. Obviously not from knowing what Don Heath's actions have } been, since he's clearly voted in favor of and cooperated with efforts } to open up the space (see what he did on the IAHC). } } Could you enlighten us where this "history" you have comes from? } } Perry } } From cclark Fri Jun 12 16:40:10 1998 Delivery-Date: Fri, 12 Jun 1998 16:49:53 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id QAA25225 for ietf-outbound.10@ietf.org; Fri, 12 Jun 1998 16:40:02 -0400 (EDT) Received: from black-ice.cc.vt.edu (black-ice.cc.vt.edu [128.173.14.71]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22342 for ; Fri, 12 Jun 1998 14:22:16 -0400 (EDT) Received: from black-ice.cc.vt.edu (localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.9.0/8.9.0) with ESMTP id OAA29276; Fri, 12 Jun 1998 14:19:49 -0400 Message-Id: <199806121819.OAA29276@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Merton Campbell Crockett Cc: "Perry E. Metzger" , "Roeland M.J. Meyer" , domain-policy@open-rsc.org, com-priv@PSI.COM, telecomreg@relay.doit.wisc.edu, ietf@ietf.org, CYBERTELECOM-L@LISTSERV.AOL.COM, DOMAIN-POLICY@lists.internic.net Subject: Re: Why do Don Heath and ISOC Risk Destruction of Internet's Chances for Self Regulation? In-Reply-To: Your message of "Fri, 12 Jun 1998 10:05:51 PDT." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-342601448P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 1998 14:19:47 -0400 --==_Exmh_-342601448P Content-Type: text/plain; charset=us-ascii On Fri, 12 Jun 1998 10:05:51 PDT, Merton Campbell Crockett said: > I'm surprised someone hasn't used HTML to show that they can yell the > loudest by using bold-face 72 point caps. Damn. Now you've done it.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_-342601448P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNYFxQtQBOOoptg9JAQHIVwP/dXXtDRHGsCUBK8MLYdYtH2s+uIn0zhQX 4Usln9E6Jo4JzHEnkeN9GU6oSXtbIzZup+E20yyYnqLrHdvImh2iWtJ1IgfrhPAU VitdUpm+TVVzdwwBvjhKWXRVB2wCRFuhThNHqB6J4GQy0uHR+iO5V2XjnhfPDgHG CYcidSCfaz0= =od2u -----END PGP MESSAGE----- --==_Exmh_-342601448P-- From cclark Tue Jun 23 11:31:58 1998 Delivery-Date: Tue, 23 Jun 1998 11:47:00 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA21490 for ietf-outbound.10@ietf.org; Tue, 23 Jun 1998 11:30:03 -0400 (EDT) Received: from hotmail.com (f228.hotmail.com [207.82.251.119]) by ietf.org (8.8.5/8.8.7a) with SMTP id LAA21206 for ; Tue, 23 Jun 1998 11:12:18 -0400 (EDT) Received: (qmail 8384 invoked by uid 0); 23 Jun 1998 15:10:56 -0000 Message-ID: <19980623151056.8383.qmail@hotmail.com> Received: from 192.31.7.244 by www.hotmail.com with HTTP; Tue, 23 Jun 1998 08:10:55 PDT X-Originating-IP: [192.31.7.244] From: "John Squires" To: cook@cookreport.com, perry@piermont.com Cc: com-priv@PSI.COM, telecomreg@relay.doit.wisc.edu, ietf@ietf.org, CYBERTELECOM-L@LISTSERV.AOL.COM, domain-policy@open-rsc.org, DOMAIN-POLICY@lists.internic.net Subject: Re: Why do Don Heath and ISOC Risk Destruction of Internet's Chances for Self Regulation? Content-Type: text/plain Date: Tue, 23 Jun 1998 08:10:55 PDT How old are you guys??? John >From cclark@ietf.org Fri Jun 12 06:11:47 1998 >Received: (from adm@localhost) > by ietf.org (8.8.5/8.8.7a) id IAA14152 > for ietf-outbound.03@ietf.org; Fri, 12 Jun 1998 08:50:01 -0400 (EDT) >Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) > by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA14023 > for ; Fri, 12 Jun 1998 08:45:27 -0400 (EDT) >Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id IAA02101; Fri, 12 Jun 1998 08:45:12 -0400 (EDT) >Message-Id: <199806121245.IAA02101@jekyll.piermont.com> >To: Gordon Cook >cc: com-priv@PSI.COM, telecomreg@relay.doit.wisc.edu, ietf@ietf.org, > CYBERTELECOM-L@LISTSERV.AOL.COM, domain-policy@open-rsc.org, > DOMAIN-POLICY@lists.internic.net >Subject: Re: Why do Don Heath and ISOC Risk Destruction of Internet's Chances for Self Regulation? >In-reply-to: Your message of "Fri, 12 Jun 1998 12:34:16 +0300." > >Reply-To: perry@piermont.com >X-Reposting-Policy: redistribute only with permission >Mime-Version: 1.0 (generated by tm-edit 7.108) >Content-Type: text/plain; charset=US-ASCII >Date: Fri, 12 Jun 1998 08:45:11 -0400 >From: "Perry E. Metzger" > > >Gordon Cook writes: >> I CAN ONLY CONCLUDE THAT THEY ARE DETERMINED TO DESTROY ANY HOPE OF >> INTERNET INDUSTRY SELF-REGULATION IF IT IS NOT DONE ON THEIR TERMS. > >Gordon, if you want people to believe your newsletter is worth buying, >you should at least learn how to find your caps lock key. > >Perry > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From cclark Sun Jul 5 22:00:17 1998 Delivery-Date: Sun, 05 Jul 1998 22:16:41 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id WAA08265 for ietf-outbound.10@ietf.org; Sun, 5 Jul 1998 22:00:04 -0400 (EDT) Received: from MailServer1.CRCCNet.Com (NS1.CRCCNet.Com [205.169.37.13]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA08240 for ; Sun, 5 Jul 1998 21:57:11 -0400 (EDT) Received: from OC1.NBCI.Net (OC1.JanAlan.Com [205.169.37.51]) by MailServer1.CRCCNet.Com (post.office MTA v1.9.3 ID# 0-13321) with SMTP id AAA103; Sun, 5 Jul 1998 19:56:13 -0600 Message-Id: <2.2.32.19980706015253.00717264@MailSys.NBCI.Net> X-Sender: NBCI.AMaitland@MailSys.NBCI.Net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 05 Jul 1998 19:52:53 -0600 To: perry@piermont.com From: "Alan J. Maitland" Subject: Re: Where is the RFC editor? Cc: Masataka Ohta , "Dick St.Peters" , ietf@ietf.org Dear Perry, At 07:37 PM 7/5/98 -0400, Perry E. Metzger wrote: > -- SNIP -- > >In general, though, why don't we drop this discussion? > >Perry > Please allow me the honor of seconding that idea. Best, Alan Maitland NBCI.Net Visit http://2000.Experience.Net/ home of the Year 2000 Challenge private satellite broadcast training event this fall - planning and coordinating Y2K issues. Technology Training... for People and Companies. From cclark Tue Jul 14 15:30:08 1998 Delivery-Date: Tue, 14 Jul 1998 15:44:54 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA09683 for ietf-outbound.10@ietf.org; Tue, 14 Jul 1998 15:30:03 -0400 (EDT) Received: from mailsvr1.iodesign.com (mailsvr1.iodesign.com [206.190.80.251]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA08684 for ; Tue, 14 Jul 1998 14:53:32 -0400 (EDT) Received: from tentacle (tide18.microsoft.com [131.107.3.28]) by mailsvr1.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NF0FM2HM; Tue, 14 Jul 1998 11:56:07 -0700 Message-ID: <08cf01bdaf58$9b7cc470$d7fd3b9d@tentacle.dns.microsoft.com> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: Cc: "Noel Chiappa" , , , , , Subject: Re: Tired of Waiting Date: Tue, 14 Jul 1998 11:52:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >No, it has just be denied by individuals like you who want to make >money by getting a profitable monopoly on public resources. The bulk >of the community has a pretty obvious interest in the other direction. Your assessment is as inaccurate as your basis for the claim. What is the difference between a registry making an honest profit and a registrar making an honest profit? If both provide good service, contractually prohibit gouging and harm to the Internet, where is the harm? For those of you recent to the discussion, please note that Perry was a member of the IAHC, the group that proposed that a single registry be created to handle all TLDs, including COM/NET/ORG (which they carefully claimed SHOULD be a part). Their plan, as you may be aware, called for registrars to pay $10,000 each just to participate (and still does). They're STILL taking this money from registrars, including a monthly fee, and they have absolutely nothing to show for it. They also changed their internal pricing in much the same way that they claim for-profit registries would. These are all public facts, and can be found by reading the various archived lists. Why do I bring this up again? Simply to show that there are seriously different PHILOSOPHIES at work here, and they are overshadowing the plain fact that if we could just put them aside, create a stable, fair, open and transparent governing body, we could then come together and resolve these problems. But people keep bringing them up. Yes, I realize that I should just ignore them and not reply, but when factual inaccuracies are posted (and I'm sure Perry will claim I've done the same, natch) and personal attacks like the above (where Perry presumes to claim to know what it is that I want) are posted, and philosophical opinions are taken as fact (like the namespace is a public resource), the loudest voice seems to claim victory. As I've said, let's stop it, and move on to more productive issues, okay? -- Christopher Ambler, Personal Opinion Only -- NOTICE: The user of this email address is a resident of the State of Washington. Washington law provides for up to $500 per incident in the case of Unsolicited Commercial Email (also known as spam). This individual WILL file a complaint. From cclark Tue Jul 14 16:50:11 1998 Delivery-Date: Tue, 14 Jul 1998 17:00:45 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id QAA15639 for ietf-outbound.10@ietf.org; Tue, 14 Jul 1998 16:50:02 -0400 (EDT) Received: from swan.prod.itd.earthlink.net (swan.prod.itd.earthlink.net [207.217.120.123]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA14185 for ; Tue, 14 Jul 1998 15:55:51 -0400 (EDT) Received: from [38.14.97.67] (ip67.wilton.ct.pub-ip.psi.net [38.14.97.67]) by swan.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id MAA14101; Tue, 14 Jul 1998 12:55:21 -0700 (PDT) Message-Id: <199807141955.MAA14101@swan.prod.itd.earthlink.net> Subject: Re: Tired of Waiting Date: Tue, 14 Jul 1998 15:46:12 -0000 x-sender: nicnic@earthlink.net x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: nicnic To: "Christopher Ambler" , cc: "Noel Chiappa" , , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >>No, it has just be denied by individuals like you who want to make >>money by getting a profitable monopoly on public resources. The bulk >>of the community has a pretty obvious interest in the other direction. > > >Your assessment is as inaccurate as your basis for the claim. What >is the difference between a registry making an honest profit and a >registrar making an honest profit? If both provide good service, >contractually prohibit gouging and harm to the Internet, where is the >harm? > >For those of you recent to the discussion, please note that Perry was >a member of the IAHC, the group that proposed that a single registry >be created to handle all TLDs, including COM/NET/ORG (which they >carefully claimed SHOULD be a part). Their plan, as you may be aware, >called for registrars to pay $10,000 each just to participate (and still >does). They're STILL taking this money from registrars, including a >monthly fee, and they have absolutely nothing to show for it. They also >changed their internal pricing in much the same way that they claim >for-profit registries would. These are all public facts, and can be found >by reading the various archived lists. > >Why do I bring this up again? Simply to show that there are seriously >different PHILOSOPHIES at work here, and they are overshadowing >the plain fact that if we could just put them aside, create a stable, fair, >open and transparent governing body, we could then come together >and resolve these problems. > >But people keep bringing them up. Yes, I realize that I should just >ignore them and not reply, but when factual inaccuracies are posted >(and I'm sure Perry will claim I've done the same, natch) and >personal attacks like the above (where Perry presumes to claim >to know what it is that I want) are posted, and philosophical >opinions are taken as fact (like the namespace is a public resource), >the loudest voice seems to claim victory. > >As I've said, let's stop it, and move on to more productive issues, >okay? > >-- >Christopher Ambler, Personal Opinion Only >-- >NOTICE: The user of this email address is a resident of the State of >Washington. Washington law provides for up to $500 per incident in >the case of Unsolicited Commercial Email (also known as spam). >This individual WILL file a complaint. > > And well written too ! Nicolas Reisini techinvest.com us-directory.com act.nyc.ny.us wall-street.nyc.ny.us From cclark Tue Jul 14 18:50:09 1998 Delivery-Date: Tue, 14 Jul 1998 19:04:01 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id SAA17957 for ietf-outbound.10@ietf.org; Tue, 14 Jul 1998 18:50:02 -0400 (EDT) Received: from ties.itu.ch (root@ties.itu.ch [156.106.192.33]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16804 for ; Tue, 14 Jul 1998 17:45:35 -0400 (EDT) Received: from itu.int (usr0-13.itu.ch [156.106.192.166]) by ties.itu.ch (8.9.1/8.9.1) with ESMTP id XAA22257; Tue, 14 Jul 1998 23:45:18 +0200 (MET DST) Message-ID: <35ABD165.45721CF3@itu.int> Date: Tue, 14 Jul 1998 23:45:10 +0200 From: Robert Shaw X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Christopher Ambler CC: perry , Noel Chiappa , ietf , List , comments , discussion-draft , domain-policy Subject: Re: Tired of Waiting References: <08cf01bdaf58$9b7cc470$d7fd3b9d@tentacle.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Ambler wrote: > > Your assessment is as inaccurate as your basis for the claim. What > is the difference between a registry making an honest profit and a > registrar making an honest profit? If both provide good service, > contractually prohibit gouging and harm to the Internet, where is the > harm? Because this is the Internet public infrastructure and not your personal playground to make a fast buck. History has taught us a big lesson. .com represents 85% of all gTLD registrations. There is a reason: gTLDs are non-portable, quasi-non-interchangeable goods (imagine 'ownership' of .inc in a world of 100 million SLD delegations). Therefore, competition between registries (aka gTLDs) is fantasy. So get over it. Become a registrar. Go forth and suffer *real* competition, not pseudo-competition because you have a lock on a gTLD. Robert -- Robert Shaw Head, a.i., IED/Advisor, Global Information Infrastructure International Telecommunication Union Place des Nations, 1211 Geneva, Switzerland From cclark Tue Jul 14 19:00:07 1998 Delivery-Date: Tue, 14 Jul 1998 19:13:35 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id TAA18172 for ietf-outbound.10@ietf.org; Tue, 14 Jul 1998 19:00:02 -0400 (EDT) Received: from mailsvr1.iodesign.com (mailsvr1.iodesign.com [206.190.80.251]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA16843 for ; Tue, 14 Jul 1998 17:49:32 -0400 (EDT) Received: from tentacle (tide18.microsoft.com [131.107.3.28]) by mailsvr1.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NF0FM2LC; Tue, 14 Jul 1998 14:52:08 -0700 Message-ID: <09b801bdaf71$323b3c30$d7fd3b9d@tentacle.dns.microsoft.com> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: "Robert Shaw" Cc: "perry" , "Noel Chiappa" , "ietf" , "List" , "comments" , "discussion-draft" , "domain-policy" Subject: Re: Tired of Waiting Date: Tue, 14 Jul 1998 14:48:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >Because this is the Internet public infrastructure and not your personal >playground to make a fast buck. History has taught us a big lesson. >.com represents 85% of all gTLD registrations. There is a reason: gTLDs >are non-portable, quasi-non-interchangeable goods (imagine 'ownership' >of .inc in a world of 100 million SLD delegations). Therefore, competition >between registries (aka gTLDs) is fantasy. So get over it. Become a registrar. >Go forth and suffer *real* competition, not pseudo-competition because you >have a lock on a gTLD. I could say the same think to CORE. I guess everyone needs to get over it, eh, Bob? -- Christopher Ambler, Personal Opinion Only -- NOTICE: The user of this email address is a resident of the State of Washington. Washington law provides for up to $500 per incident in the case of Unsolicited Commercial Email (also known as spam). This individual WILL file a complaint. From cclark Tue Jul 14 22:30:16 1998 Delivery-Date: Tue, 14 Jul 1998 22:45:10 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id WAA23483 for ietf-outbound.10@ietf.org; Tue, 14 Jul 1998 22:30:03 -0400 (EDT) Received: from MailServer1.CRCCNet.Com (NS1.CRCCNet.Com [205.169.37.13]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA21118 for ; Tue, 14 Jul 1998 21:49:25 -0400 (EDT) Received: from OC1.NBCI.Net (OC1.JanAlan.Com [205.169.37.51]) by MailServer1.CRCCNet.Com (post.office MTA v1.9.3 ID# 0-13321) with SMTP id AAA111; Tue, 14 Jul 1998 19:49:47 -0600 Message-Id: <2.2.32.19980715014409.006f1ed8@MailSys.NBCI.Net> X-Sender: NBCI.AMaitland@MailSys.NBCI.Net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jul 1998 19:44:09 -0600 To: "Christopher Ambler" , "Robert Shaw" From: "Alan J. Maitland" Subject: Tired of hearing about Re: Tired of Waiting and and and??? Cc: "perry" , "Noel Chiappa" , "ietf" , "List" , "comments" , "discussion-draft" , "domain-policy" Dear Group, Is it me or all we all starting to get a bit tired of ongoing discussions that start as business of the group and degrade to personal matters. I make a modest proposal. As long as messages stay to topic, why not keep a thread public. Those who wish to engage in the back and forth behavior, simply keep track of the back and forth threads. At the end, the least bloodied of the parties can send the results to all of us. In this way, we at least will not have to use the delete message key quite so many times in a day and the overall burden on all of our servers is reduced to one HELO per tirade session. It's okay, I did talk radio for two years, I understand public exhibitionism... really... I do =-) Best, Alan Maitland President NBCI.Net Visit http://2000.Experience.Net/ home of the Year 2000 Challenge private satellite broadcast training event this fall - planning and coordinating Y2K issues. Industry leaders joining to address the Y2K challenge. Technology Training... for People and Companies. At 03:48 PM 7/11/98 -0700, he said this: At 05:23 PM 7/12/98 -0400, he said that: At 07:56 AM 7/13/98 -0700, then he said THIS: At 01:04 PM 7/14/98 -0700, and so he got really pissed and said... And the beat goes on... From cclark Wed Jul 15 01:00:10 1998 Delivery-Date: Wed, 15 Jul 1998 01:09:47 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id BAA01969 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 01:00:02 -0400 (EDT) Received: from pooh.higgs.net (spruce.higgs.net [204.80.125.145]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01483 for ; Wed, 15 Jul 1998 00:27:14 -0400 (EDT) Received: from wntcalaxr002 (hq068009138.dcmdw.dla.mil [131.68.9.138]) by pooh.higgs.net (8.8.5/8.8.5) with SMTP id VAA01258; Tue, 14 Jul 1998 21:25:09 -0700 Message-Id: <199807150425.VAA01258@pooh.higgs.net> X-Sender: particle@pooh.higgs.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 15 Jul 1998 04:20:43 -0700 To: domain-policy@open-rsc.org From: Simon Higgs Subject: Re: Tired of Waiting Cc: Christopher Ambler , perry , Noel Chiappa , ietf , List , comments , discussion-draft In-Reply-To: <35ABD165.45721CF3@itu.int> References: <08cf01bdaf58$9b7cc470$d7fd3b9d@tentacle.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:45 PM 7/14/98 +0200, Robert Shaw wrote: >Christopher Ambler wrote: >> >> Your assessment is as inaccurate as your basis for the claim. What >> is the difference between a registry making an honest profit and a >> registrar making an honest profit? If both provide good service, >> contractually prohibit gouging and harm to the Internet, where is the >> harm? > >Because this is the Internet public infrastructure and not your personal >playground to make a fast buck. History has taught us a big lesson. You have incorrectly stated the nature of the internet. There is no public infrastructure (it was removed with the NSF routing tables). The internet is entirely a private co-operative infrastructure. That would be a PRIVATE TRUST. >.com represents 85% of all gTLD registrations. There is a reason: gTLDs >are non-portable, quasi-non-interchangeable goods (imagine 'ownership' >of .inc in a world of 100 million SLD delegations). Therefore, competition >between registries (aka gTLDs) is fantasy. So get over it. Become a registrar. >Go forth and suffer *real* competition, not pseudo-competition because you >have a lock on a gTLD. Not bad coming from someone with a solid lock on a TLD. Or is the ITU planning on adding .INT to the CORE database? You should, as it'll be the only TLD that actually works there. The real reason .COM was allowed to get so large was because the IAHC (which you were a member) completely and thoroughly screwed up. The international community called you on it, won, and consequently there are no new TLDs yet. I think you, Bob, should personally take a large portion of the blame for the .COM zone getting so big. Best Regards, Simon -- ### From cclark Wed Jul 15 02:00:10 1998 Delivery-Date: Wed, 15 Jul 1998 02:10:47 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id CAA06951 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 02:00:02 -0400 (EDT) Received: from condor.mhsc.com ([199.108.175.226]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA06909 for ; Wed, 15 Jul 1998 01:57:25 -0400 (EDT) Received: from hawk (hawk.lvrmr.mhsc.com [199.108.175.236]) by condor.mhsc.com (8.8.8/8.8.8) with SMTP id WAA10080; Tue, 14 Jul 1998 22:54:20 -0700 Message-Id: <199807150554.WAA10080@condor.mhsc.com> X-Sender: rmeyer@pop.mhsc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 14 Jul 1998 22:54:20 -0700 To: domain-policy@open-rsc.org From: "Roeland M.J. Meyer" Subject: Re: Tired of Waiting Cc: Christopher Ambler , perry , Noel Chiappa , ietf , List , comments , discussion-draft , domain-policy In-Reply-To: <35ABD165.45721CF3@itu.int> References: <08cf01bdaf58$9b7cc470$d7fd3b9d@tentacle.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:45 PM 7/14/98 +0200, Robert Shaw wrote: >Christopher Ambler wrote: >> >> Your assessment is as inaccurate as your basis for the claim. What >> is the difference between a registry making an honest profit and a >> registrar making an honest profit? If both provide good service, >> contractually prohibit gouging and harm to the Internet, where is the >> harm? > >Because this is the Internet public infrastructure and not your personal >playground to make a fast buck. History has taught us a big lesson. What lesson is that? >.com represents 85% of all gTLD registrations. There is a reason: gTLDs >are non-portable, quasi-non-interchangeable goods (imagine 'ownership' >of .inc in a world of 100 million SLD delegations). I was thinking more along the lines of each ISP eventually having their own TLD, if for nothing more than to support their web-hosting business. It also allows better control over VPNs, certainly an easier way to remember them. At the moment, we are using private TLDs for this. It also lets one build meta-nets. MHSC is on the cusp of casting such a meta-net of VPNs. Yes, there is lock-in, but in this case, if someone wants to dis-connect from our meta-net, we want them to remove all affiliations, including the TLD. >Therefore, competition >between registries (aka gTLDs) is fantasy. So get over it. Become a registrar. >Go forth and suffer *real* competition, not pseudo-competition because you >have a lock on a gTLD. If someone doesn't like what we are doing then they can leave. They can always go back to COM. Domain re-naming isn't nearly as bad as an IP re-number. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: www.mhsc.com/~rmeyer Company web-site: www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon! From cclark Wed Jul 15 11:40:12 1998 Delivery-Date: Wed, 15 Jul 1998 11:50:03 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA18187 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 11:40:03 -0400 (EDT) Received: from condor.mhsc.com ([199.108.175.226]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17891 for ; Wed, 15 Jul 1998 11:33:10 -0400 (EDT) Received: from hawk (hawk.lvrmr.mhsc.com [199.108.175.236]) by condor.mhsc.com (8.8.8/8.8.8) with SMTP id IAA10878; Wed, 15 Jul 1998 08:31:52 -0700 Message-Id: <199807151531.IAA10878@condor.mhsc.com> X-Sender: rmeyer@pop.mhsc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 15 Jul 1998 08:31:51 -0700 To: perry@piermont.com From: "Roeland M.J. Meyer" Subject: Re: Tired of Waiting Cc: "Richard J. Sexton" , List@giaw.org, ietf@ietf.org, comments@iana.org, discussion-draft@giaw.org In-Reply-To: <199807150112.VAA12317@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:12 PM 7/14/98 -0400, Perry E. Metzger wrote: > >"Richard J. Sexton" writes: >> Chris has little to be a flake about. You register the domain via a web >> form. You make updates to it via a web form, there are half a dozen >> nameservers or so for that TLD. >> >> If Chris is a flake, he doesnt get paid. I would consider that to >> be incentive. > >One would have thought this to be true, but NSI has proven both ideas >to be wrong. First of all, you will pay and pay, regardless, because >you can't afford to have your domain name disrupted. False, you pay because there is nowhere else to go. NSI really was messing up bad for a long while, and they were arrogantly unresponsive as well. This has since changed, thank God. However, it did highlight a problem. There was no, and still isn't, any choice. All of us in NET or COM have no choice. If one is in the US then there is REALLY NO CHOICE. >We have also >determined that even the simple business of assuring a database is >kept up to date can be mammothly screwed up -- NSI has done so, on >many occassions. Still screwed up. No DB integrity. >> Sure the prices *should* drop, I'll go you one further and say >> they should be free. But, there appears to be enough of a consensus >> that there should be a minimum price of $35/yr to encourage garabge >> collection of unused names and to discourage runs on registries. > >I don't see any reason to set minimum or other prices -- that's price >fixing, which the anti-trust laws discourage, and which I, as a free >marketeer, don't believe in. The market will set the price on things >fairly if we let it. That requires name portability and competition, >however. > >> >I have no evidence that supports your claim. I also suspect that >> >competition in the area would drive prices down to a small rate of >> >return over cost. >> >> Try looking at a few CORE registrars, Perry. Let me know if you >> find one thats $35. > >None of them are operating, so there are no prices from any of them >for anything. There is no operating CORE registry at the >moment. Unlike, say, Chris Ambler or Eugene Kashpureff, CORE doesn't >pretend to be able to sell a service it currently cannot sell. We don't either. We actually have private TLDs working. GRS is fine also. Right now, untill the roots get opened up, we are deploying on GRS. >> Also consider that some poeple may prefer paying less and living with >> poor service as opposed to paying CORE prices and getting their >> hand held. > >The point of CORE is to allow people to choose to pay for service, or >not, as they freely wish in the marketplace. Some registrars for, say, >.COM, could offer extensive handholding at a high price. Some could >offer minimal service and a very low price, say $10 or $15. The whole >point of CORE is to permit this sort of tradeoff to occur freely in >the marketplace. Why not give out a list of CORE registrars so we can all go take a look? ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: www.mhsc.com/~rmeyer Company web-site: www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon! From cclark Wed Jul 15 12:40:09 1998 Delivery-Date: Wed, 15 Jul 1998 12:49:49 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA19731 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 12:40:01 -0400 (EDT) Received: from po1.namesecure.com (qmailr@po1.namesecure.com [205.229.232.3]) by ietf.org (8.8.5/8.8.7a) with SMTP id MAA19095 for ; Wed, 15 Jul 1998 12:12:30 -0400 (EDT) Received: (qmail 1893 invoked by uid 100); 15 Jul 1998 16:12:29 -0000 Date: Wed, 15 Jul 1998 09:12:29 -0700 (PDT) From: Patrick Greenwell To: "Perry E. Metzger" cc: ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org, domain-policy@open-rsc.org Subject: Re: Tired of Waiting In-Reply-To: <199807151607.MAA16094@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, Perry E. Metzger wrote: > > Patrick Greenwell writes: > > On Tue, 14 Jul 1998, Noel Chiappa wrote: > > > > > PS: Didn't we just have the US Congress mandate "number portability" for > > > local phone companies to prevent just this kind of "lock-in" - and for much > > > the same reason, which is that it's much harder to change your phone number > > > than your credit card number. > > > > Please, when customers are guaranteed IP portability, let me know.... > > Phone numbers aren't like IP addresses. IP addresses are much more > like routing information -- the stuff that is permanent in the IP > world is the domain name, not the IP address. Phone numbers aren't like routing information? Then why do we have area codes and exchange prefixes? Further, I would love to have a truly permanent, portable IP address(es). I imagine lots of folks would. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v Systems Administrator (925) 377-1414 f NameSecure \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From cclark Wed Jul 15 13:50:08 1998 Delivery-Date: Wed, 15 Jul 1998 14:00:07 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA21162 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 13:50:02 -0400 (EDT) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA20964 for ; Wed, 15 Jul 1998 13:34:34 -0400 (EDT) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Jul 15 13:28:40 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Wed Jul 15 13:32:20 EDT 1998 Received: from smb.research.att.com (volvo.research.att.com [135.207.23.62]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id NAA17368; Wed, 15 Jul 1998 13:32:17 -0400 (EDT) Message-Id: <3.0.3.32.19980715173212.008ad770@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 15 Jul 1998 17:32:12 +0000 To: Patrick Greenwell From: "Steven M. Bellovin" Subject: address portability Cc: "Perry E. Metzger" , ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org In-Reply-To: References: <199807151607.MAA16094@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: > >Further, I would love to have a truly permanent, portable IP address(es). >I imagine lots of folks would. Right. Lots of people would. The problem is that at present, it's simply not technically feasible. Portable IP addresses -- even on a corporate scale, where the units routed are networks, not hosts -- would imply a very large increase in the size of the global routing table. And that's problematic, partly because of the memory requirements -- routers don't use the SIMMs you buy at your corner computer store -- but because of the computational complexity of the routing table calculations. And that issue, in turn, is exacerbated by the desire for the Internet to respond quickly to changes in topology, which in turn means that the calculations need to be done rather frequently. It may be that new algorithms and techniques will make this point moot. For now, the best approach is to adopt technologies that make addresses less visible and less permanent, such as IPv6 with automatic renumbering. Or perhaps IPv6's large address space will let us experiment with other techniques, such as geographical addressing and metropolitan area exchanges. For now, though, I think we have to live with topology-based addressing -- not because anyone wants to, but because the technology doesn't exist to do otherwise. I should note that this issue, unlike most of the others, is almost purely technical. If anyone has any *detailed, technical* refutations -- and not simply assertions that topology-based addresses are wrong, or a bare claim that the problem is solved -- I'd be interested in hearing it. You're right, of course, that today it is an important issue. But I for one don't know how to solve it, nor to my knowledge do the IETFers I respect. From cclark Wed Jul 15 14:00:11 1998 Delivery-Date: Wed, 15 Jul 1998 14:12:36 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA21352 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 14:00:02 -0400 (EDT) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by ietf.org (8.8.5/8.8.7a) with SMTP id NAA21325 for ; Wed, 15 Jul 1998 13:59:28 -0400 (EDT) Received: by ginger.lcs.mit.edu id AA04431; Wed, 15 Jul 98 13:48:16 -0400 Date: Wed, 15 Jul 98 13:48:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9807151748.AA04431@ginger.lcs.mit.edu> To: ietf@ietf.org, patrick@namesecure.com Subject: Re: Tired of Waiting Cc: List@giaw.org, comments@iana.org, discussion-draft@giaw.org, domain-policy@open-rsc.org, jnc@ginger.lcs.mit.edu, perry@piermont.com From: Patrick Greenwell > Phone numbers aren't like routing information? Then why do we have area > codes and exchange prefixes? You will note that the "local number portability" is just that - *local* portability. Move from one state in the US to another, and get a new phone number. And even LNP is being done with Yet Another Giant Mapping Database, so that when your incoming call arrives at a LATA, the IEC knows which LEC to give it to. In other words, your "phone number" here in the New World Order *doesn't* contain your exchange any more - rather, it's a portable "phone name" which has to be mapped into a *real* phone number befire the phone switches can route the call. In other words, a phone number under LNP is just like a DNS name - it has to be mapped into a real location before being useful. People don't think of them that way because the *syntax* is identical - looks like a phone numbers, works like a phone number. But they aren't really line numbers any more. > Further, I would love to have a truly permanent, portable IP > address(es). Sure. Now, remembering the above details about how LNP really works, with mapping on all inbound calls, please explain to us the details: are you going to emit packets with these "portable" IP "addresses" in them? If so, what happens: does each individual router along the path do a mapping before routing the packet - or does the first hop router do the lookup once and modify the packet? (If so, what about TCP checksums - not to mention authentication...) Gee, guys, where's Tim Bass? Maybe we could get him to explain all this to Mr. Greenwell... :-) (Tim, if you're listening, my apologies in advance!) Noel From cclark Wed Jul 15 14:20:13 1998 Delivery-Date: Wed, 15 Jul 1998 14:35:54 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA21690 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 14:20:02 -0400 (EDT) Received: from po1.namesecure.com (qmailr@po1.namesecure.com [205.229.232.3]) by ietf.org (8.8.5/8.8.7a) with SMTP id OAA21608 for ; Wed, 15 Jul 1998 14:17:27 -0400 (EDT) Received: (qmail 22990 invoked by uid 100); 15 Jul 1998 18:17:28 -0000 Date: Wed, 15 Jul 1998 11:17:28 -0700 (PDT) From: Patrick Greenwell To: "Steven M. Bellovin" cc: "Perry E. Metzger" , ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org Subject: Re: address portability In-Reply-To: <3.0.3.32.19980715173212.008ad770@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, Steven M. Bellovin wrote: > At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: > > > >Further, I would love to have a truly permanent, portable IP address(es). > >I imagine lots of folks would. > > Right. Lots of people would. The problem is that at present, it's > simply not technically feasible. Portable IP addresses -- even on a > corporate scale, where the units routed are networks, not hosts -- would > imply a very large increase in the size of the global routing table. That really depends on what you consider a network. /30? /29? /24? Certainly Sprint could remove their (now) assinine filter tomorrow, and I don't think you would see a very large increase in the size of the global routing table. Most providers announce /24's already anyways. At any rate, I wasn't saying that personalized, individual IP portability is technically feasible at this time, just that it would be nice. Perhaps we could ask the telco industry, who is working on what seems to me to be a fairly similar issue with phone number portability. :-) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v Systems Administrator (925) 377-1414 f NameSecure \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From cclark Wed Jul 15 15:30:11 1998 Delivery-Date: Wed, 15 Jul 1998 15:40:55 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id PAA23241 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 15:30:02 -0400 (EDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22515 for ; Wed, 15 Jul 1998 14:54:57 -0400 (EDT) Received: from [128.89.30.6] (JOHNDAY.BBN.COM [128.89.14.113]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id OAA23671; Wed, 15 Jul 1998 14:54:54 -0400 (EDT) X-Sender: day@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.19980715173212.008ad770@127.0.0.1> References: <199807151607.MAA16094@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jul 1998 14:54:51 -0400 To: "Steven M. Bellovin" , Patrick Greenwell From: John Day Subject: Re: address portability Cc: "Perry E. Metzger" , ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org At 13:32 -0400 7/15/98, Steven M. Bellovin wrote: >At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: >> >>Further, I would love to have a truly permanent, portable IP address(es). >>I imagine lots of folks would. But it wouldn't be an address. Noel, you want to explain this or is it worth it? From cclark Wed Jul 15 16:00:09 1998 Delivery-Date: Wed, 15 Jul 1998 16:09:44 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id QAA23987 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 16:00:02 -0400 (EDT) Received: from po1.namesecure.com (qmailr@po1.namesecure.com [205.229.232.3]) by ietf.org (8.8.5/8.8.7a) with SMTP id PAA23045 for ; Wed, 15 Jul 1998 15:20:26 -0400 (EDT) Received: (qmail 17074 invoked by uid 100); 15 Jul 1998 19:20:25 -0000 Date: Wed, 15 Jul 1998 12:20:25 -0700 (PDT) From: Patrick Greenwell To: John Day cc: "Steven M. Bellovin" , "Perry E. Metzger" , ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org Subject: Re: address portability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, John Day wrote: > At 13:32 -0400 7/15/98, Steven M. Bellovin wrote: > >At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: > >> > >>Further, I would love to have a truly permanent, portable IP address(es). > >>I imagine lots of folks would. > > But it wouldn't be an address. > > Noel, you want to explain this or is it worth it? Oh, please do. :-) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v Systems Administrator (925) 377-1414 f NameSecure \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From cclark Wed Jul 15 16:20:21 1998 Delivery-Date: Wed, 15 Jul 1998 16:30:13 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id QAA24562 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 16:20:03 -0400 (EDT) Received: from sparticus.eurekanet.com (root@sparticus.eurekanet.com [206.150.170.3]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24510 for ; Wed, 15 Jul 1998 16:18:23 -0400 (EDT) From: mpistone@eurekanet.com Received: from eurekanet.com (root@sparticus.eurekanet.com [206.150.170.3]) by sparticus.eurekanet.com (8.8.5/8.8.5) with SMTP id QAA19521; Wed, 15 Jul 1998 16:14:25 -0400 (EDT) Sender: mpistone@eurekanet.com Reply-to: mpistone@eurekanet.com To: "Steven M. Bellovin" Cc: "Perry E. Metzger" , ietf@ietf.org, List@giaw.org Date: Wed, 15 Jul 98 16:14:33 +400 Subject: Re: address portability X-Mailer: DMailWeb Web to Mail Gateway 1.5af, http://netwinsite.com/top_mail.htm Message-id: <35ad0da9.4c3a.0@eurekanet.com> X-User-Info: 206.150.170.42 If you follow the telco solution if would make matters a total mess. Basicly (going from memory here) if the phone number is no longer served by the ILEC then they callers ILEC must consult one of several (5?) Natial Phone # Portabilty Databases and find out the CLEC that has that number. Then the ILEC passes the call off to the CLEC. If you translate this to the Internet then the system would first contact the backbone that was assigned the original block that the address belongs to. If that provider realized it no longer has that network then it contacts a master database (or seperate routing table) and forwards the packets over to the new provider for that network... Obviously that idea stinks. I think everyone can agree that portiblity is ideal but not even near practicle right now. -Mike >On Wed, 15 Jul 1998, Steven M. Bellovin wrote: > >> At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: >> > >> >Further, I would love to have a truly permanent, portable IP address(es). >> >I imagine lots of folks would. >> >> Right. Lots of people would. The problem is that at present, it's >> simply not technically feasible. Portable IP addresses -- even on a >> corporate scale, where the units routed are networks, not hosts -- would >> imply a very large increase in the size of the global routing table. > >That really depends on what you consider a network. /30? /29? /24? >Certainly Sprint could remove their (now) assinine filter tomorrow, and I >don't think you would see a very large increase in the size of the global >routing table. Most providers announce /24's already anyways. > >At any rate, I wasn't saying that personalized, individual IP portability >is technically feasible at this time, just that it would be nice. >Perhaps we could ask the telco industry, who is working on what seems >to me to be a fairly similar issue with phone number portability. :-) > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >Patrick Greenwell (800) 299-1288 v > Systems Administrator (925) 377-1414 f > NameSecure >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > > From cclark Wed Jul 15 16:50:13 1998 Delivery-Date: Wed, 15 Jul 1998 16:59:55 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id QAA25415 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 16:50:04 -0400 (EDT) Received: from mailsvr1.iodesign.com (mailsvr1.iodesign.com [206.190.80.251]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25068 for ; Wed, 15 Jul 1998 16:33:48 -0400 (EDT) Received: from tentacle (tide18.microsoft.com [131.107.3.28]) by mailsvr1.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NF0FM29W; Wed, 15 Jul 1998 13:36:22 -0700 Message-ID: <0af601bdb02f$c691fe50$d7fd3b9d@tentacle.dns.microsoft.com> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: , "Scott Bradner" Cc: , , , , Subject: Re: Tired of Waiting Date: Wed, 15 Jul 1998 13:33:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >I actually believe in a fully open process. However, email is not >structured to make that feasible. In a committee hearing, you can >follow things like Roberts Rules of Order to make sure that giving >everyone their say is orderly. In email, you can't do that, which >means you can't operate a fully open process using only email. I actually agree with Perry on this one, which is why I'm going well out of my way to attend the meetings (DC, Geneva, etc). I feel we make much more progress at these meetings than over the lists. By far. -- Christopher Ambler, Personal Opinion Only -- NOTICE: The user of this email address is a resident of the State of Washington. Washington law provides for up to $500 per incident in the case of Unsolicited Commercial Email (also known as spam). This individual WILL file a complaint. From cclark Wed Jul 15 17:30:07 1998 Delivery-Date: Wed, 15 Jul 1998 17:42:00 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA26253 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 17:30:02 -0400 (EDT) Received: from kudonet.com ([165.227.52.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id RAA26074 for ; Wed, 15 Jul 1998 17:20:01 -0400 (EDT) Received: by kudonet.com (SMI-8.6/SMI-SVR4) id OAA14106; Wed, 15 Jul 1998 14:19:52 -0700 Received: from kudo20.kudonet.com(209.133.125.67) by kudonet.com via smap (V2.0) id xma014102; Wed, 15 Jul 98 14:19:34 -0700 Received: by kudo20.kudonet.com (SMI-8.6/SMI-SVR4) id OAA29311; Wed, 15 Jul 1998 14:19:15 -0700 Received: from unknown(209.133.124.92) by mail.kudonet.com via smap (V2.0) id xma029301; Wed, 15 Jul 98 14:19:10 -0700 Message-ID: <35AD1CDA.EEDEF31@ttcinc.com> Date: Wed, 15 Jul 1998 14:19:22 -0700 From: halkhatib Organization: TTC of Silicon Valley, Inc. X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: mpistone@eurekanet.com CC: "Steven M. Bellovin" , "Perry E. Metzger" , ietf@ietf.org, List@giaw.org Subject: Re: address portability References: <35ad0da9.4c3a.0@eurekanet.com> Content-Type: multipart/mixed; boundary="------------A84F37C4644D696B09E1FA00" This is a multi-part message in MIME format. --------------A84F37C4644D696B09E1FA00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The problem of portability can be resolved by strictly using domain names as permanent identifiers of portable devices. The dynamically assigned IP address to a portable device is then associated with the domain name using a DNS server with dynamic update. Although the use of domain names has so far been limited to "convenience", we believe that it is also key to resolving the IPv4 address depletion problem and may eliminate the need for NAT or IPv6. Hasan Alkhatib mpistone@eurekanet.com wrote: > If you follow the telco solution if would make matters a total mess. Basicly > (going from memory here) if the phone number is no longer served by the ILEC > then they callers ILEC must consult one of several (5?) Natial Phone # Portabilty > Databases and find out the CLEC that has that number. Then the ILEC passes > the call off to the CLEC. > > If you translate this to the Internet then the system would first contact the > backbone that was assigned the original block that the address belongs to. > If that provider realized it no longer has that network then it contacts a master > database (or seperate routing table) and forwards the packets over to the new > provider for that network... Obviously that idea stinks. I think everyone > can agree that portiblity is ideal but not even near practicle right now. > > -Mike > > >On Wed, 15 Jul 1998, Steven M. Bellovin wrote: > > > >> At 09:12 AM 7/15/98 -0700, Patrick Greenwell wrote: > >> > > >> >Further, I would love to have a truly permanent, portable IP address(es). > > >> >I imagine lots of folks would. > >> > >> Right. Lots of people would. The problem is that at present, it's > >> simply not technically feasible. Portable IP addresses -- even on a > >> corporate scale, where the units routed are networks, not hosts -- would > > >> imply a very large increase in the size of the global routing table. > > > >That really depends on what you consider a network. /30? /29? /24? > >Certainly Sprint could remove their (now) assinine filter tomorrow, and I > >don't think you would see a very large increase in the size of the global > >routing table. Most providers announce /24's already anyways. > > > >At any rate, I wasn't saying that personalized, individual IP portability > >is technically feasible at this time, just that it would be nice. > >Perhaps we could ask the telco industry, who is working on what seems > >to me to be a fairly similar issue with phone number portability. :-) > > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > >Patrick Greenwell (800) 299-1288 v > > Systems Administrator (925) 377-1414 f > > NameSecure > >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > > > > > > > --------------A84F37C4644D696B09E1FA00 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hasan Alkhatib Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Hasan Alkhatib n: Alkhatib;Hasan org: TTC of Silicon Valley, Inc. adr: 900 Lafayette Street;;Suite 705;Santa Clara;CA;95050-4967;USA email;internet: halkhatib@ttcinc.com title: President tel;work: (408)249-3200 tel;fax: (408)249-3400 tel;home: (408)868-9299 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------A84F37C4644D696B09E1FA00-- From cclark Wed Jul 15 18:10:09 1998 Delivery-Date: Wed, 15 Jul 1998 18:22:11 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id SAA26900 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 18:10:02 -0400 (EDT) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26847 for ; Wed, 15 Jul 1998 18:02:34 -0400 (EDT) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id RAA00780; Wed, 15 Jul 1998 17:00:33 -0500 (CDT) Received: from dal-tx2-55.ix.netcom.com(207.94.120.183) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma000731; Wed Jul 15 17:00:03 1998 Message-ID: <35ACC10D.D5A6F36A@ix.netcom.com> Date: Wed, 15 Jul 1998 15:47:44 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 4.04 [en] (Win16; I) MIME-Version: 1.0 To: perry@piermont.com CC: Scott Bradner , discussion-draft@giaw.org, ietf@ietf.org, ifwp@ifwp.org, List@giaw.org, rmeyer@mhsc.com Subject: Re: Tired of Waiting References: <199807152019.QAA22579@jekyll.piermont.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Perry and all, Perry E. Metzger wrote: > Scott Bradner writes: > > jeff asks > > > Why would anybody be filtered out if you truly believe in an open process? > > > > because history shows some people contribute volume not content? > > http://golem.sobco.com/nww/1997/08-democracy.html > > I actually believe in a fully open process. However, email is not > structured to make that feasible. In a committee hearing, you can > follow things like Roberts Rules of Order to make sure that giving > everyone their say is orderly. In email, you can't do that, which > means you can't operate a fully open process using only email. God you are misinformed Kent!!! You can certainly VOTE using a Web page app. It is done every day in one forum or another. And any E-mail mailing list can be open to anyone besides that point. You can also use a FREE form mailing list to have compleat input unrestricted thereby allowing an open process to anyone that wishes to participate. > > > Perry regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com From cclark Wed Jul 15 22:50:12 1998 Delivery-Date: Wed, 15 Jul 1998 22:59:25 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id WAA01122 for ietf-outbound.10@ietf.org; Wed, 15 Jul 1998 22:50:02 -0400 (EDT) Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by ietf.org (8.8.5/8.8.7a) with SMTP id WAA01056 for ; Wed, 15 Jul 1998 22:40:57 -0400 (EDT) Received: from localhost (ses@localhost) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id WAA08794; Wed, 15 Jul 1998 22:40:47 -0400 Date: Wed, 15 Jul 1998 22:40:47 -0400 (EDT) From: Simon Spero To: John Day cc: "Steven M. Bellovin" , Patrick Greenwell , "Perry E. Metzger" , ietf@ietf.org, List@giaw.org, comments@iana.org, discussion-draft@giaw.org Subject: Re: address portability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Jul 1998, John Day wrote: > Noel, you want to explain this or is it worth it? [Noel Chiappa had a farm EIEID...] If no-one has any objection, I will setup a daemon to automically post random postings from the big-internet archive until we all travel sufficiently far back in time that we can prevent the spice girls from meeting. ObLibel: Postel didn't write 793 - bacon did From cclark Thu Jul 16 14:50:11 1998 Delivery-Date: Thu, 16 Jul 1998 15:01:27 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA19862 for ietf-outbound.10@ietf.org; Thu, 16 Jul 1998 14:50:02 -0400 (EDT) Received: from mailsvr1.iodesign.com (mailsvr1.iodesign.com [206.190.80.251]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA19208 for ; Thu, 16 Jul 1998 14:12:39 -0400 (EDT) Received: from tentacle (tide77.microsoft.com [131.107.3.77]) by mailsvr1.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NF0FMJL7; Thu, 16 Jul 1998 11:15:11 -0700 Message-ID: <000501bdb0e5$3a7b4b40$d7fd3b9d@tentacle.dns.microsoft.com> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: , "Richard J. Sexton" Cc: , , , Subject: Re: Tired of Waiting Date: Thu, 16 Jul 1998 11:12:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >> Why doesnt CORE just use IOD instead of emergent? > >IOD didn't bid on the contract. Emergent bid on the contract. Exactly. CORE is using Emergent. IOD is using IOD, the company chose to do it themselves. >The central locking database maintained by CORE is just that -- a >database. It is not a business. It isn't set up to take payments, make >payments, handle incoming orders, handle phone support or phone calls, >or any of the other things that would make it a business. It is just >an organization that maintains an Oracle database in a closet. The >registrars are not "middle men". They are doing virtually all of the >actual work. > >The only thing the CORE database does is make sure that they don't >step on each other's feet and provide a central source for the DNS >information to be generated from. A fine system, to be sure. For that matter, if, as expected, the mandate is that registries and registrars must separate themselves, it's entirely logical that IOD would remove the registrar functions and become, strictly, a registry. At that point, the $35 fee could very well drop dramatically. Right now, IOD is set up as registry AND registrar. Some work has been done, I'm told, to get those ready to be separated if need be. This is one of a few reasons why the previous price comparison was somewhat presumptive. -- Christopher Ambler, Personal Opinion Only -- NOTICE: The user of this email address is a resident of the State of Washington. Washington law provides for up to $500 per incident in the case of Unsolicited Commercial Email (also known as spam). This individual WILL file a complaint. From cclark Thu Jul 16 17:40:12 1998 Delivery-Date: Thu, 16 Jul 1998 17:51:53 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id RAA22510 for ietf-outbound.10@ietf.org; Thu, 16 Jul 1998 17:40:02 -0400 (EDT) Received: from mailsvr1.iodesign.com (mailsvr1.iodesign.com [206.190.80.251]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22477 for ; Thu, 16 Jul 1998 17:38:21 -0400 (EDT) Received: from tentacle (tide77.microsoft.com [131.107.3.77]) by mailsvr1.iodesign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id NF0FMJQ2; Thu, 16 Jul 1998 14:40:55 -0700 Message-ID: <002001bdb101$f7fc6980$d7fd3b9d@tentacle.dns.microsoft.com> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: Cc: , , , Subject: Re: Ambler pretends to own .WEB again. Date: Thu, 16 Jul 1998 14:37:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >A court already pretty much eliminated your claim to .WEB for you, >like it or not, or have you forgotten that little detail? I know it is >mighty convenient for you to continue pretending in public that you >had a legitimate claim to .WEB to begin with, but I believe the matter >has been fully settled at this point. The judge practically laughed >you out of court. At that point, to avoid pay our court costs, you >asked the Judge's permission to drop the case. Were you to chose to >try reopening the case, you'd almost certainly be denied the motion. Not only are you wrong on a number of points, but, I have to, once again, repeat my mantra to you: The Case Was Not About That. >No one has to believe me on this. I'm including, YET AGAIN, the >transcript of what the Judge said, officially, in an actual court of >law, on this subject. See the end of this message for said transcript. Yes, please read it everyone, as Perry goes to the trouble to post it every week or so. Remember, please, that the judge is commenting only on IOD's request for a TRO to prevent the signing of the MoU. The lawyers on this list will realize that Perry's assessment above does not mesh with the judge's decision. >I'm utterly astonished by your continuing public claims in the >matter. Have you not the least bit of shame? I should ask the same of you. Personally, I don't much care for your assessment. If it ends up back in court, perhaps I'll see you there. I would take a lot of personal pleasure in seeing you on the witness stand. Have a nice day. See you in Geneva? -- Christopher Ambler, Personal Opinion Only -- NOTICE: The user of this email address is a resident of the State of Washington. Washington law provides for up to $500 per incident in the case of Unsolicited Commercial Email (also known as spam). This individual WILL file a complaint. From cclark Thu Jul 16 21:20:11 1998 Delivery-Date: Thu, 16 Jul 1998 21:29:42 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id VAA24736 for ietf-outbound.10@ietf.org; Thu, 16 Jul 1998 21:20:02 -0400 (EDT) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA24701 for ; Thu, 16 Jul 1998 21:18:02 -0400 (EDT) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA16634; Thu, 16 Jul 1998 18:17:34 -0700 (PDT) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id SAA09580; Thu, 16 Jul 1998 18:17:13 -0700 (PDT) Message-Id: <3.0.5.32.19980716181109.01373e00@stilton.cisco.com> X-Sender: fred@stilton.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Jul 1998 18:11:09 -0700 To: perry@piermont.com, "Christopher Ambler" From: Fred Baker Subject: Re: Ambler pretends to own .WEB again. Cc: ietf@ietf.org In-Reply-To: <199807162248.SAA00160@cctvw02.cctec.com> References: <002001bdb101$f7fc6980$d7fd3b9d@tentacle.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 07:27 PM 7/16/98 -0400, Perry E. Metzger wrote: >"Christopher Ambler" writes: >> Can we drop this? > >No. We can not. But you can take your childish ad hominem debate somewhere else. Anywhere else, I don't care, as long as I'm not on it. You have both been asked, both privately and publicly, by me and by others. KNOCK IT OFF! At 06:27 PM 7/16/98 -0400, Eric Germann wrote: >Thanks folks, for destroying an engineering list. I concur. From cclark Fri Jul 17 02:22:01 1998 Delivery-Date: Fri, 17 Jul 1998 02:33:25 -0400 Return-Path: cclark Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id CAA04401 for ietf-outbound.10@ietf.org; Fri, 17 Jul 1998 02:21:58 -0400 (EDT) Received: from condor.mhsc.com ([199.108.175.226]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA04359 for ; Fri, 17 Jul 1998 02:17:58 -0400 (EDT) Received: from hawk (hawk.lvrmr.mhsc.com [199.108.175.236]) by condor.mhsc.com (8.8.8/8.8.8) with SMTP id XAA13300; Thu, 16 Jul 1998 23:15:14 -0700 Message-Id: <199807170615.XAA13300@condor.mhsc.com> X-Sender: rmeyer@pop.mhsc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 16 Jul 1998 23:15:13 -0700 To: perry@piermont.com From: "Roeland M.J. Meyer" Subject: Re: Ambler pretends to own .WEB again. Cc: domain-policy@open-rsc.org, List@giaw.org, ietf@ietf.org, discussion-draft@giaw.org In-Reply-To: <199807162152.RAA03911@jekyll.piermont.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 05:52 PM 7/16/98 -0400, Perry E. Metzger wrote: > >"Christopher Ambler" writes: >> >A court already pretty much eliminated your claim to .WEB for you, >> >like it or not, or have you forgotten that little detail? I know it is >> >mighty convenient for you to continue pretending in public that you >> >had a legitimate claim to .WEB to begin with, but I believe the matter >> >has been fully settled at this point. The judge practically laughed >> >you out of court. At that point, to avoid pay our court costs, you >> >asked the Judge's permission to drop the case. Were you to chose to >> >try reopening the case, you'd almost certainly be denied the motion. >> >> Not only are you wrong on a number of points, but, I have to, once again, >> repeat my mantra to you: The Case Was Not About That. > >Oh, yes? Well, that isn't what your complaint to the court said, and >it isn't what the judge seems to think your claims were. He >specifically addressed this, in fact: > >"[....]There we have the claim of Image Online that >they have a proprietary and protectable interest in dot web. > I find the evidence insufficient to support either >factually, or as a matter of law, that the Plaintiff has established >that it has protectable proprietary interest in the term -- >or the word -- term `dot web,'[...]" > >You seem to believe that by claiming repeatedly that something didn't >happen that other people will start believing you. >Lets get this clear, once more. You sued. You lost. You keep claiming, >counterfactually, that you did not lose. You weasel in every direction >you can. He only sought injunctive reilef.... Aiya, you're to ignorant to waste any more time on >You have no legal right to .WEB. You sued to get it. You did not get >it. > >You are like the knight at the bridge in Monty Python's "Holy Grail", >who, after having had both arms and legs cut off, insists that he has >not lost the fight. > >For those who've missed it, I, once again, provide what the judge >said. > >Perry > >[Transcript follows.] >---------------------------------------------------------------------- > THE COURT: Anything further? All right. I'm prepared >to rule. > One, I find that the Plaintiff, Image Online, has not >met its burden of proof to establish a reasonable likelihood of >prevailing on the merits of Image Online's claims at the time of >trial. Those claims are really -- there are three different >claims or categories of claims. One is the breach of contract >theory. > There's insufficient evidence presented to support that >there was an enforceable agreement that was entered into between >Plaintiff and the Defendants. > What's most interesting about the breach of con- > >tract/estoppel claim is that the claim made is that there was a >contract entered into, or that the Defendant should be estopped >from denying that a contract was entered into with an entity that >the Plaintiff claims has no authority to act. And in drawing that >conclusion, I don't mean to oversimplify and sound cute about the >inconsistency, but there's a real internal inconsistency in the >breach of contract position and again, the failure to establish >the elements of a contract. > The second category of claims really has to do with the >unfair competition. There we have the claim of Image Online that >they have a proprietary and protectable interest in dot web. > I find the evidence insufficient to support either >factually, or as a matter of law, that the Plaintiff has estab- > >lished that it has protectable proprietary interest in the term -- >or the word -- term "dot web," considering the nature of the >interweb and the usage of the term, vis a vis, the interweb -- the >Internet. > The third category has to do with the anti-competition, >the anti-trust theories. Here, I find that the evidence provided >by the Defendants supports the Defendant's claim that the proposed >memorandum of understanding -- I don't know if it's a fait accom- > >pli at this point. I realize the meaning is taking place now, or >may be concluded, but at least for my purposes is a proposed >memorandum of understanding. As I understand the memorandum of >understanding, the memorandum is promotive of competition. And I >would categorize it as pro competition. It's purpose is certainly >-- does not appear to be to stifle competition. And even assuming >that the elements of the combination have been established, at >least for the purposes of the temporary restraining order applica- > >tion, any appropriate application of the anti-trust rule of reason >considering, as applied to the Internet, suggests to me that >there's certainly justification for the combination acting as it >is. And in particular, it's very difficult for me to ignore the >evidence before me that those that are involved, at least these >Defendants, have no proprietary or profit motive in their under- > >takings, whereas the Plaintiff has. > Furthermore, I find that the evidence is just not suffi- > >cient to support the claim of the Plaintiff, that either any of >these Defendants, whether it be the IANA or the Ad Hoc Committee, >or the Internet Society are acting in an anti-competitive manner. > There again, the anomaly we have here is that if the >Plaintiff had its way, it would be willing to enter into an agree- > >ment with a combination that it believes is acting to restrain >trade. > I further find that if the Plaintiff does have legal >rights against any of these Defendants, that their remedy, if any, >is -- can be compensated in monetary damages. > There's also been a failure on the Plaintiff to estab- > >lish irreparable harm justifying the imposition of injunctive >relief. Even assuming if I'm -- that my analysis is incorrect >that the Plaintiff does not have an adequate legal remedy, that's >to say monetary damages, what I have done is -- what I'm obligated >to do, and that is to weigh the equities and consider the harm to >the Plaintiff if injunctive relief is not granted versus the harm >to the Defendants, and each and all of them, if injunctive relief >is granted. And when I refer to Defendants, "and each and all of >them," I'm referring, even though the Internet itself -- I don't >know how you could make the Internet itself a Defendant, but I -- >what I've considered in terms of the damage to the Defendants, by >extension, is the damage to the Internet system. And I've weighed >the respective harms if I don't grant injunctive relief as the >Plaintiff requested, and the harm if I do. > And the disruption to the Internet -- to the -- and the >potential destabilization and disruption to the Internet so far >outweighs the potential harm that there is harm to the Plaintiff, >that frankly, I don't even think it's a close call when I weigh >the equities and find the equities favor not granting injunctive >relief. > And I must tell you, notwithstanding, Mr. Walter, your >argument in connection with the extent of the interstate commerce >clause and the ability of the Cartwright Act, to act as a long arm >of California law and extend overseas, I do have, as I understand, >the -- and it's not that I came upon this myself, it's clearly in >one of the briefs, the reference to the -- to what appears to be >congressional policy, although not the force of law, but that >congress prefers that the Internet not be fettered with the -- >with governmental regulation, either by the federal government or >the state government. > I do have a great deal of concern about a California >trial court involving itself when considered with all the other -- >the global implications, the fact that -- of the Internet, the >fact that there is no, per se, regulatory body, I concern myself >when I gave consideration to the matter of potential disruption of >the Internet and destabilization of the Internet to the question >of whether or not there ought to be enforcement of a state law in >this case, 17200 of the Business and Professions Code or, for that >matter, the Cartwright Act, to the activities of the Internet. It >certainly caused me to hesitate as to the appropriateness, in view >of what appears to be clear cut congressional policy. > So, for all of those reasons, the temporary restraining >order is denied. And for the reasons that I've indicated earlier, >I don't feel it's appropriate to set this matter for an order to >show cause re preliminary injunction. That should take care of >it. >---------------------------------------------------------------------- > ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: www.mhsc.com/~rmeyer Company web-site: www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon! From wsimpson@greendragon.com Mon Jul 20 12:45:41 1998 Delivery-Date: Mon, 20 Jul 1998 12:45:41 -0400 Return-Path: wsimpson@greendragon.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA18678 for ; Mon, 20 Jul 1998 12:45:40 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04820 for ; Mon, 20 Jul 1998 12:45:27 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA18671 for ; Mon, 20 Jul 1998 12:45:30 -0400 (EDT) Received: from pm365-13.dialip.mich.net (pm365-13.dialip.mich.net [207.75.186.23]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA00598; Mon, 20 Jul 1998 12:45:22 -0400 (EDT) Date: Mon, 20 Jul 98 16:34:42 GMT From: "William Allen Simpson" Message-ID: <7415.wsimpson@greendragon.com> To: iesg@ietf.org cc: perry@piermont.com, karn@qualcomm.com Subject: RFC-1829 to historic! -----BEGIN PGP SIGNED MESSAGE----- Because of the recent events in cracking single DES, I formally request that our RFC-1829 be declared Historic. Perry concurs, but I've not yet heard from Phil. As an interim solution, I will repost my DESX and 3DES drafts for approval as Proposed Standards, as modified (the silly explicit IV) by the IPSec WG, and with another Informational companion for backward compatibility with RFC-1851, which is currently Experimental. The long term future solution is likely to be somthing like CAST-128 or the final AES, but there is insufficient consensus and analysis for those alternatives, and it will be years. We need an interim solution. > Date: Sat, 18 Jul 1998 17:41:45 -0400 > From: "Perry E. Metzger" > > "William Allen Simpson" writes: > > Would you be willing to join me in asking the IESG to reclassify our > > RFC-1829 as Historic? I think that it would be a nice touch for a > > "standards organization" to formally obsolete DES. > > Absolutely. > > .pm > -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNbNlstm/qMj6R+sxAQF2cwP8CUOav2wccNSudzLlh+CYDwZDr+xwMN56 gBDb/eLJgcxu+zzP7eBbt1d8wN0yTcA+R1W09fII23eHnBvz5hf6QYrfV+Hpmwnv StnMjDVtydebdMbaZ3yOEvJ4Z3tqy/PtTUlGIigKo5ImO6vX9vUnBKtF3iII8ekP w3MKOZvY06A= =G88+ -----END PGP SIGNATURE----- From perry@jekyll.piermont.com Mon Jul 20 13:06:37 1998 Delivery-Date: Mon, 20 Jul 1998 13:06:37 -0400 Return-Path: perry@jekyll.piermont.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA18800 for ; Mon, 20 Jul 1998 13:06:36 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04953 for ; Mon, 20 Jul 1998 13:06:28 -0400 (EDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA18797 for ; Mon, 20 Jul 1998 13:06:34 -0400 (EDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA12346; Mon, 20 Jul 1998 13:06:18 -0400 (EDT) Message-Id: <199807201706.NAA12346@jekyll.piermont.com> To: "William Allen Simpson" cc: iesg@ietf.org, perry@piermont.com, karn@qualcomm.com Subject: Re: RFC-1829 to historic! In-reply-to: Your message of "Mon, 20 Jul 1998 16:34:42 GMT." <7415.wsimpson@greendragon.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 20 Jul 1998 13:06:18 -0400 From: "Perry E. Metzger" "William Allen Simpson" writes: > As an interim solution, I will repost my DESX and 3DES drafts for > approval as Proposed Standards, as modified (the silly explicit IV) by > the IPSec WG, and with another Informational companion for backward > compatibility with RFC-1851, which is currently Experimental. There are new 3DES etc. drafts from the working group, aren't there? I agree that as a symbolic act, the DES RFC be made Historic as quickly as possible, but we should let the working group do its job in replacing it, probably with 3DES. Perry From wsimpson@greendragon.com Mon Jul 20 17:19:22 1998 Delivery-Date: Mon, 20 Jul 1998 17:19:22 -0400 Return-Path: wsimpson@greendragon.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22470 for ; Mon, 20 Jul 1998 17:19:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06861 for ; Mon, 20 Jul 1998 17:19:12 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA22466 for ; Mon, 20 Jul 1998 17:19:17 -0400 (EDT) Received: from pm368-13.dialip.mich.net (pm368-13.dialip.mich.net [207.75.186.113]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA05536; Mon, 20 Jul 1998 17:18:22 -0400 (EDT) Date: Mon, 20 Jul 98 20:59:09 GMT From: "William Allen Simpson" Message-ID: <7416.wsimpson@greendragon.com> To: perry@piermont.com cc: iesg@ietf.org, karn@qualcomm.com Subject: Re: RFC-1829 to historic! > From: "Perry E. Metzger" > There are new 3DES etc. drafts from the working group, aren't there? > Nope. The WG is completely disfunctional. Just like they could not agree 3 years ago to make 3DES a proposed standard, and we had to go with experimental, they still could not agree on 3DES last year. So, 3DES was stuck on the back burner, and combined into a document of other optional algorithms like RC5-40, CAST-40, and other such cruft. I have a deep antipathy toward that document, for both technical and process reasons. IMnsHO, the Cisco folks are behaving just like Bound did at the Plenary a few years back over DES, saying we should "standardize" bad algorithms, because they are going to be limited to them anyway and so they will have to ship them. They don't face up to the fact that they are going to get their pants beaten off competitively. > I agree that as a symbolic act, the DES RFC be made Historic as > quickly as possible, but we should let the working group do its job in > replacing it, probably with 3DES. > We've waited for the WG yet another year. Let the WG finish off the Kent Arch, AH, and ESP revisions, and disband. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32