Re: Not sure if this is the right place for this
On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote: So a secure ports only policy has very little to do with security and very much to do with organizational power relationships, and making your computing environment dysfunctional. Somebody check my math on this please, but it seems to me that the whole STARTTLS approach is succeptible to a specific attack which the secure socket model is not. Your math is incorrect in that both STARTTLS and the separate port approach are vulnerable to this attack. In the separate port case an attacker has only to block the separate port completely, forcing a fallback to the regular port. (Not providing fallback in such cases is rarely a viable option.) It is also possible to interfere with the TLS negotiation itself, causing negotiation of unacceptably weak security. All of these attacks can be twarted by requiring (on either the client or server or both) a certain level of security. We've been providing the necessary knobs to enforce this for quite a few years now; I'm fairly sure other vendors have similar knobs. Unless that's wrong for some reason, I'd say that a secure ports policy actually is more secure. It isn't. See above. Ned ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Not sure if this is the right place for this
So a secure ports only policy has very little to do with security and very much to do with organizational power relationships, and making your computing environment dysfunctional. Somebody check my math on this please, but it seems to me that the whole STARTTLS approach is succeptible to a specific attack which the secure socket model is not. A man-in-the-middle can just as easily (more easily, in fact, since it doesn't require datastream modification) send back a port-unreachable to the client's attempt to contact the foo-over-ssl port. It is true, as you imply, that if either the client or the server has a SSL/TLS-required policy, then a non-SSL/TLS connection won't get made. This policy can be configured into endpoints using STARTTLS if that's desired. If clients and servers both permit the use of cleartext reusable passwords to be negotiated, then a MITM will be able to force them into it in either case. At a theoretical level there isn't much difference between the two security-wise. Arguments about which is better in practice depend on assumptions about what implementors and deployers and users might or might not do. The underlying reason why the separate-port approach loses, though, is that it makes simplistic assumptions about the relationships between services on different ports. Do imap://example.com/ and imaps://example.com/ provide access to the same resource? There's no reason to believe that they do in the general case. The separate-port approach wires-in assumptions about what's on a port that are easily circumvented later, both by bad guys and good guys (as we tend toward a world where everything runs over port 80). - RL Bob ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Complaint on abuse of DNSOP lists
Speaking as OPS AD who is currently on-line. The other OPS AD (David Kessens) is in the air and so is Harald. Please refrain from this discussion on the DNSOP mailing list. I have seen the complaint and will investigate and come with an answer. The issue was between Dean and one of Rob Austein's email addresses, so I do not see a need to discuss this on this mailing list. So I declare this subject as a topic that is NOT a DNSOP mailing list topic. Pls refrain from posting to this list on this topic. Thanks, Bert (OPS AD) -Original Message- From: Dean Anderson [mailto:[EMAIL PROTECTED] Sent: maandag 10 mei 2004 22:10 To: Pekka Savola Cc: Harald Tveit Alvestrand; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Complaint on abuse of DNSOP lists On Mon, 10 May 2004, Pekka Savola wrote: On Mon, 10 May 2004, Dean Anderson wrote: Point of order, please It seems that WG co-chair has begun to use an email address that is defaming Av8 Internet, Inc by returning business email to users of Av8 Internet claiming that Av8 Internet has hijacked some address space. Av8 Internet hereby demands that the IETF immediately end this behavior and halt the defamation of Av8 Internet, Inc by IETF representatives. IETF representatives must use email addresses that are not configured for defamation of Av8 Internet, Inc. If you look at the message, you will note that it is a bounce from the WG co-chair's _personal_ email address, directly to your email address. Actually, it bounces this way to all Av8 Internet Customers, not just to me. But it was a bounce to a message Mr. Austein posted on DNSOP. It was not private business. It was IETF business. Further, by reviewing the archives of DNSOP, I have found that Mr. Austein's home address is [EMAIL PROTECTED], which he has used exclusively for some time until March 1st of this year. He first started using the ISC.ORG address on a message involving draft-ietf-dnsop-inadr-required. Perhaps coincidentally, this draft is a pet project of Mr. Austeins, and one to which I (and many others) have raised serious objections regarding both misleading and incorrect content and procedural irregularities. The archives show that since March 1st, 2004, Mr. Austein has made all his DNSOP posts from [EMAIL PROTECTED] I'd say that everyone has the right to choose what mail to accept (or not to accept). They don't when they are conducting IETF business. IETF rules require that participants not be excluded from IETF activities. WG chairs and others cannot refuse email from participants. As Joe Abley revealed previously, this configuration from ISC.ORG isn't meant to actually block spam. The idea is to make Av8 Internet users have to seek other email addresses by which to contact them, and to obtain opportunities to defame Av8 Internet and perhaps others and convince users to seek other services. This is unlawful. Besides the defamation, it would is an illegal group boycott, and an unfair business practice. Refusing email is one thing, though that is still not permitted for IETF business. Defamation by claiming addresses are hijacked is quite another thing. This abuse of email addresses is unacceptable, and illegal, and I can engage legal action if necessary to prevent an organization like the IETF from permitting this abuse to continue. Mr. Austein cannot be allowed to use the ISC.ORG address for IETF business. You might or might not have a point if this behaviour happened on an IETF list, but that is not the case.. Actually, it is the case. This involves two IETF lists, and the conduct of an IETF representative on the DNSOP list. My republishing of Mr. Austein's defamation to the DNSOP and IETF list to make a complaint is a republishment for which Mr. Austein and the IETF are legally responsible under US defamation tort law. Mr Austein as a representative of the IETF defamed Av8 Internet to me, to the customers of Av8 Internet, and to the readership of both the IETF and DNSOP lists. Mr. Austein is a co-chair of the IETF working group. This defamation came about through IETF working group business. The IETF is responsible for the conduct of its representatives on its lists. It is unlawful to permit its representatives to use addresses which are configured to defame IETF participants, and it is against the IETF rules to refuse email from IETF participants. Dean Anderson President Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET (ISC.ORG upstream) says he has no contract with me to accept complaints about ISC.ORG. --Dean Dean... you are asserting a relationship that you have no way to prove exists. Unless or until you can prove that ep.net is an upstream for isc.org, please refrain from making such statements. Traceroute is not your friend in this case. Defamation works many ways. --bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
assignment of IP space does not impune any other service. Asserting otherwise is foolish. Pressing the point, esp. in public fora, appears to be willful ignorance. Please enjoy your blissful state. --bill On Tue, May 11, 2004 at 02:02:45PM -0400, Dean Anderson wrote: The following message indicates that EP.NET has assigned an IP address to ISC.ORG. You are quite well aware of this. Dissembling will not help you. --Dean Date: Thu, 15 Jan 2004 10:26:42 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: bill [EMAIL PROTECTED] Subject: Re: Complaint regarding www.sorbs.net (204.152.186.189) (fwd) On Wed, 14 Jan 2004, bill wrote: I have no reason to act as your relay agent. We have no agreement in place for me to act in this manner. The traceroute I forwarded shows that your IP addresses 198.32.176.4 is assigned to ISC.ORG, which typically indicates a relationship. 8 paix-gw4.isc.org (198.32.176.4) 92.828 ms 91.036 ms 91.415 ms On Mon, 10 May 2004 [EMAIL PROTECTED] wrote: but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET (ISC.ORG upstream) says he has no contract with me to accept complaints about ISC.ORG. --Dean Dean... you are asserting a relationship that you have no way to prove exists. Unless or until you can prove that ep.net is an upstream for isc.org, please refrain from making such statements. Traceroute is not your friend in this case. Defamation works many ways. --bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Not sure if this is the right place for this
On the other hand, STARTTLS *requires* a clear channel that the client MUST *already* be using. So whereas the attack on SSL *might* succeed in putting the client in touch with an unencrypted service, TLS is *guaranteed* to be using such a service already anyway. The only question is whether or not a decipherable login can be used, which is a probability mask that also applies to the SSL scenario. Exactly right. This is the strongest argument in favor of protected ports over STARTTLS. Another argument in favor of separate ports is an implementation issue: It is fairly common in large scale deployments to have specialized hardware to perform SSL/TLS stuff, and that hardware often is not resident on the same machines that offer POP/SMTP/IMAP services. This means that proxy that delves a bit into the underlying protocol is needed to do STARTTLS. Unfortunately proxies are in practice responsible for far more bugs you'd expect and the proxy has to dig into the protocol the worse things get. Separate ports, on the other hand, are much easier to implement on a front end. The counter argument to this is the separation of the SSL/TLS layer from the protocol layer is actually a bad thing security-wise. More specifically, when it is done as a separate layer information about the SSL/TLS negotiation tends to remain at that layer. Not making this information available to the application protocol makes implementation of some security schemes, including but not limited to SASL external, problematic. So, while STARTTLS is in some senses more complex, it is useful complexity. IMO this counterargument is fairly compelling. Add in the other issues that come up with separate ports (RL Bob Morgan has already summarized them nicely so I see no reason to repeat them here) leads me to conclude that STARTTLS is the way to go. Ned ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
DNSOP list members - A friendly reminder about the list setup: DNSOP, the Domain Name System Operations WG list. Questions about the administration of this list should be addressed to [EMAIL PROTECTED] Posts intended for the entire list should be addressed to [EMAIL PROTECTED] If you plan to post from more than one email address, please send a list of secondary posting addresses to: [EMAIL PROTECTED] with a subjecy line that reads: dnsop secondary posting request To unsubscribe yourself from this list send a message to '[EMAIL PROTECTED]' with the contents: unsubscribe dnsop end or go to the web based user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html The Mhonarc web archive can be found here: http://darkwing.uoregon.edu/~llynch/dnsop/index.html A list of the text archive files (month by month) can be found by sending an index request (index dnsop) to [EMAIL PROTECTED] and files can be retrived using the majordomo get command: get dnsop dnsop.archive.xxx --- Note that the list is archived is several ways and in several places, so anyone can read the WG list at their pleasure. Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774/Cell: 912-7998 On Tue, 11 May 2004, Dean Anderson wrote: On Mon, 10 May 2004, Harald Tveit Alvestrand wrote: Dean, third time same complaint, third time same answer. No. A WG chair is expected to read mail coming from the working group list. What he does with copies that go directly to him is his own business. I disagree. A WG chair has to read email from participants, including off-list email. Certain complaints and business needs to be handled off-list. And as I have told you on the previous two instances of this complaint: Personal mail to you, including bounce messages, is not someone defaming you in the IETF, even when you choose to make it public. I disagree, and I believe the IETF attorney has advised you otherwise. The previous complaints involving Paul Vixie and Joe Abley regarded their roles as participants, not as representatives of the IETF. Dean Anderson Av8 Internet, Inc . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
if you are serious, please feel free to contact your legal council to persue remedies. On Tue, May 11, 2004 at 03:32:27PM -0400, Dean Anderson wrote: I can't parse your statement. I didn't say assignment of IP space __impunes__ a service. Perhaps you meant to say that your assignment of IP address space to abusers doesn't impune the rest of your services. This was the claim made by Media3 in Media3 v. MAPS. Media3 lost. But assignment of IP address space does indicate a relationship. Your denials of that relationship are frivolous. Now, as in January, a close read of your message reveals that you didn't actually _deny_ the relationship, you tried to convince me that there was no _proof_ of any relationship. With regard to spam, we call such deniable relationships pink contracts. The spam-hoster tries to deny that anyone has any proof there is a relationship with the spammer. I'd love to be able to say you were violating you AUP, but you don't have one published. Indeed, it is rather interesting that neither EP.NET (Bill Manning), nor ISC.ORG (Paul Vixie) had published AUPs. But as Media3 V. MAPS demonstrated, we can call a spade a spade. You host abusers, we can call you abuse-friendly. I suspect this is off-topic from the subject of abuse on DNSOP lists. I would like to redirect anyone who would like to continue this offlist. I will shortly put all of your January emails and you current emails regarding EP.NET and ISC.ORG on the web under IADL.ORG (Internet Anti-Defamation League). --Dean On Tue, 11 May 2004 [EMAIL PROTECTED] wrote: assignment of IP space does not impune any other service. Asserting otherwise is foolish. Pressing the point, esp. in public fora, appears to be willful ignorance. Please enjoy your blissful state. --bill On Tue, May 11, 2004 at 02:02:45PM -0400, Dean Anderson wrote: The following message indicates that EP.NET has assigned an IP address to ISC.ORG. You are quite well aware of this. Dissembling will not help you. --Dean Date: Thu, 15 Jan 2004 10:26:42 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: bill [EMAIL PROTECTED] Subject: Re: Complaint regarding www.sorbs.net (204.152.186.189) (fwd) On Wed, 14 Jan 2004, bill wrote: I have no reason to act as your relay agent. We have no agreement in place for me to act in this manner. The traceroute I forwarded shows that your IP addresses 198.32.176.4 is assigned to ISC.ORG, which typically indicates a relationship. 8 paix-gw4.isc.org (198.32.176.4) 92.828 ms 91.036 ms 91.415 ms On Mon, 10 May 2004 [EMAIL PROTECTED] wrote: but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET (ISC.ORG upstream) says he has no contract with me to accept complaints about ISC.ORG. --Dean Dean... you are asserting a relationship that you have no way to prove exists. Unless or until you can prove that ep.net is an upstream for isc.org, please refrain from making such statements. Traceroute is not your friend in this case. Defamation works many ways. --bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Where would you suggest I take it? It says in the IETF mission statement: The IETF will pursue this mission in adherence to the following cardinal principles: Open process - that any interested participant can in fact participate in the work, know what is being decided, and make his or her voice heard on the issue. Part of this principle is our commitment to making our documents, our WG mailing lists, our attendance lists and our meeting minutes publicly available on the Net. How can one have an open process if WG chairs don't receive email? How can it be taken off-list if IETF staff don't receive email? Your request seems to be contradictory. --Dean On Tue, 11 May 2004, Rick Wesson wrote: Dean, ok, i asked nicely and privately several times. PLEASE! take this thread some place else. -rick On Tue, 11 May 2004, Dean Anderson wrote: On Mon, 10 May 2004, Noel Chiappa wrote: So? Rob's not refusing to accept *any* email *at all* from you as a person (just from a range of addresses which are generating email he doesn't like); and you're more than savvy enough technically to get email to him via some other path. As an IETF WG chair, he's obligated to follow the IETF rules on public participation. He can't block anything that the IETF mail server can't block: Public Participants. He's not under any more obligation to accept email from you via whatever channel you feel like using, no matter how onerous for him, than he is to accept messages written on 12' long oak logs of 3' diameter. Get a life, will you? Your constant whining and flaming is really getting old. You're getting really close to the line at which I'd ask the Chair to ban you from posting. Oh wait, I know what your response would be - you'd sue us. And you seem to think the rest of the world is doing things which is making you look bad. Here's another free clue: you're doing a far better job of that than the rest of us could do with a decade of free time. I'm entitled to particpate, and I'm entitled to send email to the WG chairs as a participant. One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. Dean Anderson Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
On 10 May 2004, at 16:10, Dean Anderson wrote: As Joe Abley revealed previously, this configuration from ISC.ORG isn't meant to actually block spam. What? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
On 11 May 2004, at 14:26, Dean Anderson wrote: One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. What? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
On 11 May 2004, at 14:02, Dean Anderson wrote: The following message indicates that EP.NET has assigned an IP address to ISC.ORG. You are quite well aware of this. Dissembling will not help you. For the benefit of less-operational people here who don't see humour in this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area. Some of Dean's mail servers are listed on SORBS. ISC's MXes use SORBS. Perhaps we should move on. Joe ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
I would ignore this, but it materially mis-states ISC.ORGS involvement in SORBS. ISC.ORG __HOSTS__ www.sorbs.net on 204.152.186.189: On Tue, 11 May 2004, Joe Abley wrote: For the benefit of less-operational people here who don't see humour in this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area. This block is assigned to EP.NET. Some of Dean's mail servers are listed on SORBS. ISC's MXes use SORBS. Perhaps we should move on. ISC does more than just __USE__ SORBS. It hosts and promotes SORBS. Host abuse, you are abuse-friendly. /usr/sbin/traceroute 204.152.186.189 traceroute to 204.152.186.189 (204.152.186.189), 30 hops max, 38 byte packets 1 av8-camb-gw1 (198.3.136.1) 1.548 ms 0.869 ms 1.758 ms 2 av8-qncy-gw1 (130.105.32.14) 4.338 ms 4.197 ms 4.125 ms 3 qcy1-ar2-f2-0-314.gnaps.net (199.232.42.53) 4.105 ms 3.812 ms 4.504 ms 4 qcy-m20-ge2-3-0-625.gnaps.net (199.232.44.45) 6.874 ms 4.224 ms 7.064 ms 5 ash-m20-at-0-2-0.gnaps.net (199.232.44.53) 16.136 ms 16.263 ms 16.145 ms 6 nyc-m20-ge2-1-0.gnaps.net (199.232.131.16) 24.379 ms 27.903 ms 22.061 ms 7 los1-m20-at1-3-0.gnaps.net (199.232.44.10) 99.734 ms 94.698 ms 101.074 ms 8 paix-gw4.isc.org (198.32.176.4) 103.482 ms 103.255 ms 103.596 ms 9 r2-sfo2.r5.sql1.isc.org (192.5.4.248) 106.342 ms 110.758 ms 115.882 ms 10 www.dnsbl.us.sorbs.net (204.152.186.189) 106.122 ms 110.523 ms 105.857 ms As you can see, traffic to 204.152.186.189 transits EP.NET's 198.32.176.4 address block. --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
On 11 May 2004, at 17:55, Dean Anderson wrote: I would ignore this, but it materially mis-states ISC.ORGS involvement in SORBS. ISC.ORG __HOSTS__ www.sorbs.net on 204.152.186.189: For a more complete list of resources hosted at ISC, you might try: http://www.isc.org/ops/hosting On Tue, 11 May 2004, Joe Abley wrote: For the benefit of less-operational people here who don't see humour in this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area. This block is assigned to EP.NET. [...] As you can see, traffic to 204.152.186.189 transits EP.NET's 198.32.176.4 address block. If you are interested in learning about exchange points, peering, transit and interconnection in general, I'd can give you some pointers: you're missing some basic information which is leading you to jump to the wrong conclusions wrt 198.32.176.0/24. I do lots of community education, and I'm more than willing to help out. But let's do it in private mail rather than this list. Joe ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [dnsop] Re: Complaint on abuse of DNSOP lists
I sent a response to Rob in regard to a post he made on DNSOP, and he responded that my IP addresses were hijacked. --Dean On Tue, 11 May 2004, Richard Barr Hibbs wrote: while Rob and I have had serious disagreements about technical matters in the past, I've never known him to make disparaging remarks about anyone, and a scan of the last 30 days' messages on the DNSOP list authored by Rob (and delivered to my inbox) show NONE that mention AV8, it's products, customers, or business practices. So, what's the fuss about? Doesn't seem to involve IETF at all --Barr Hibbs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dean Anderson Sent: Monday, 10 May 2004 13:24 To: John Stracke Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [dnsop] Re: Complaint on abuse of DNSOP lists On Mon, 10 May 2004, John Stracke wrote: Dean Anderson wrote: It seems that WG co-chair has begun to use an email address that is defaming Av8 Internet, Inc How is it defamation if the only one that gets the message is Av8? Av8 customers get it. DNSOP and IETF list members have gotten it. When I have to republish something to make a complaint then legally it is just like Mr. Austein published it himself. Defamation Tort Law. --Dean . dnsop resources: _ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
--On 11. mai 2004 17:10 -0400 Joe Abley [EMAIL PROTECTED] wrote: For the benefit of less-operational people here who don't see humour in this, 198.32.176.0/24 is the PAIX IPv4 peering fabric in the Bay Area. Some of Dean's mail servers are listed on SORBS. ISC's MXes use SORBS. Perhaps we should move on. Yes, please. The topic has lost all information value relevant to the IETF list. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Dean, third time same complaint, third time same answer. No. A WG chair is expected to read mail coming from the working group list. What he does with copies that go directly to him is his own business. And as I have told you on the previous two instances of this complaint: Personal mail to you, including bounce messages, is not someone defaming you in the IETF, even when you choose to make it public. Harald --On 10. mai 2004 14:17 -0400 Dean Anderson [EMAIL PROTECTED] wrote: Point of order, please It seems that WG co-chair has begun to use an email address that is defaming Av8 Internet, Inc by returning business email to users of Av8 Internet claiming that Av8 Internet has hijacked some address space. Av8 Internet hereby demands that the IETF immediately end this behavior and halt the defamation of Av8 Internet, Inc by IETF representatives. IETF representatives must use email addresses that are not configured for defamation of Av8 Internet, Inc. Dean Anderson Av8 Internet, Inc -- Forwarded message -- Date: Sun, 9 May 2004 20:17:23 -0400 From: Mail Delivery Subsystem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Returned mail: see transcript for details The original message was received at Sun, 9 May 2004 20:17:14 -0400 from cirrus.av8.net [130.105.36.66] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 553 Service unavailable; Client host [130.105.36.66] blocked using dnsbl.sorbs.net; Hijacked/Disused Netblock See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66) - Transcript of session follows - ... while talking to mx-1.isc.org.: DATA 553 Service unavailable; Client host [130.105.36.66] blocked using dnsbl.sorbs.net; Hijacked/Disused Netblock See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.36.66 550 5.1.1 [EMAIL PROTECTED]... User unknown 554 Error: no valid recipients ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
--On 10. mai 2004 09:33 -0400 Scott Bradner [EMAIL PROTECTED] wrote: this misses one of the outcomes listed in RFC 2026 - specifically (quoting from 2026): the IESG recommends that the document be brought within the IETF and progressed within the IETF context this path has been used from time to time and I think it is a valuable option - I'd suggest that it be added as a 6th response actually it was more-or-less intentionally left out. There are 3 scenarios to consider, I think: - There is a valid reason why it's impossible to do this work outside of the IETF. Response 4 or 5 should be returned, explaining why. - The work can be done in the IETF, and the author agrees. The author should (IMHO) be the one to inform the RFC Editor that he/she is dropping the request to publish outside IETF review. - The work can be done in the IETF (or rather, this draft could be the basis for further work in the IETF), but the author wants it published independently anyway. In this case, I think it is good for the health of the RFC series AND for the time budget of the IESG that the IESG does NOT say should be brought in to the RFC Editor; the IESG, having failed to convince the author, should just live with the RFC Editor's judgment on publication. My opinion only. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Not sure if this is the right place for this
On 5/10/2004 10:31 AM, Paul Hoffman / VPNC wrote: At 9:38 AM -0500 5/10/04, Eric A. Hall wrote: Using an encrypted port just means an attack can only produce failure, rather than inducing fallback. Unless that's wrong for some reason, I'd say that a secure ports policy actually is more secure. In many cases, a client for a secure ports policy protocol will fall back to the insecure port instead of telling the user you can't communicate. That's not true for HTTPS, but it is true for secure POP, secure SMTP, and so on. This is a fair enough point, and I should have accounted for it, but I don't think its absence weakens the merits of the first point any. I'm not even sure they are similar arguments. I mean, the argument against SSL is that *if* an SSL connection is blocked, and *if* an alternative clear channel exists, and *if* that channel accepts clear-text logins, and *if* the client fallsback through all of that, then the session will be exposed. I'll grant that it's easy enough to interfere with somebody establishing a session, and that there's a measurable percentage of services that maintain clear channel alternatives, and that PLAIN/LOGIN are still the only things that work everywhere, and that there are probably clients which fallback invisibly. I can also argue some of those points to some degree -- that people who have setup SSL versions are likely to have eliminated access to the clear channel, for example -- so instead of any of those things being certainties, we should agree that this is a question of overlapping probabilities. On the other hand, STARTTLS *requires* a clear channel that the client MUST *already* be using. So whereas the attack on SSL *might* succeed in putting the client in touch with an unencrypted service, TLS is *guaranteed* to be using such a service already anyway. The only question is whether or not a decipherable login can be used, which is a probability mask that also applies to the SSL scenario. Given the collection of probabilities, therefore, starting with an SSL channel and refusing connections to a backup clear channel eliminates most of the probability from the MitM attack model. Conversely, those attributes are prerequisites to the very existence of TLS. Ergo, TLS is weaker against this particular vector, by design. I don't think it really matters given the other problems (see below). A man-in-the-middle can more easily block the secure port than he/she can elide the STARTTLS messing in the client's start-up. That's true. On the other hand, channeling clients through a proxy is easy, especially if they are on a foreign network. The client can be tricked into using a different host via DNS attacks, or can simply be routed through proxies, NATs, firewalls, or any number of 'transparent' proxies that can be easily deployed. STARTTLS can be disabled by any of these, using a two-bit attack (literally: borrow one bit from the T and hand it to the S, causing the service to be advertised as TSARTTLS -- I've seen worse than that from unintentional bugs and intentional features alike). Any client that is willing to back down to non-secure mode is susceptible to a MITM attack, regardless of the protocol. agreed on that -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Problem of blocking ICMP packets
On 11-mei-04, at 6:47, Mark Smith wrote: The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. ^ And this is where all the problems start. This flies directly in the face of the the robustness principle. If the host would just set the DF bit in one in 1000, one in 100 or one in 10 packets, we wouldn't be in this mess. Note that the RFC doesn't say the DF bit must be set on ALL packets. But then, it also doesn't say this shouldn't be done either. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
Pete, I thought I was describing the status quo and what is currently happening. Unless the IAB has handed off that responsibility to the IESG in the last two years (in which case the community wasn't told), the IESG's having any discussion at all with the RFC Editor about an IAB document -- what is in that category, how they are handled, etc.-- is because the IAB asks for that discussion. It presumably also occurs in a three-way environment, even if the IAB decides to be silent about particular aspects of the conversation. john --On Monday, May 10, 2004 10:27 AM -0500 Pete Resnick [EMAIL PROTECTED] wrote: On 5/10/04 at 10:54 AM -0400, John C Klensin wrote: --On Monday, May 10, 2004 9:33 AM -0400 Scott Bradner [EMAIL PROTECTED] wrote: looks good to me - one suggestion of clearer language and a potential addition o Documents for which special rules exist, including IAB documents and April 1st RFCs, and republication of documents from other SDOs - the IESG and the RFC Editor keep a running dialogue on which documents these are awkward wording - maybe you want to say o The IESG and the RFC Editor keep a running dialogue on which documents require special rules (for example, IAB documents, April 1st RFCs, and republication of documents from other SDOs) Scott, while I agree that the current language is not optimal, I don't think the above is the right fix. The whole point of the agreements about publication of IAB documents is that the RFC Editor reports, from an overall policy and strategy standpoint, with the IAB. Turning that situation into the IESG and the RFC Editor keep a running dialogue rather dramatically revises (or confuses) that situation. John, the paragraph which Scott aims to fix is in the section which describes what is currently happening. And, indeed, I believe it is true that the current state of affairs is that the IESG and the RFC Editor *do* keep a running dialogue about out-of-the-ordinary documents which may or may not need IESG review (where republication of certain SDO documents do -- because of liaison agreements -- and April 1st RFCs do not, as far as I know). Perhaps this would be better stated as: o The IESG and the RFC Editor keep a running dialogue on which documents require special rules (for example, IAB informational documents and April 1st RFCs never require IESG review, whereas certain republication of documents from other SDOs do because of liaison agreements) (assuming that captures what Harald, and Scott, intended in their attempts). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
--On 10. mai 2004 09:33 -0400 Scott Bradner [EMAIL PROTECTED] wrote: this misses one of the outcomes listed in RFC 2026 - specifically (quoting from 2026): the IESG recommends that the document be brought within the IETF and progressed within the IETF context this path has been used from time to time and I think it is a valuable option - I'd suggest that it be added as a 6th response actually it was more-or-less intentionally left out. There are 3 scenarios to consider, I think: - There is a valid reason why it's impossible to do this work outside of the IETF. Response 4 or 5 should be returned, explaining why. not the case I'm speaking of - I'm speaking of new work that the IESG feels would be a good new IETF topic or that it fits within the charter of an existing WG (and maybe the author did not know that) and the IESG feels that it would be good to have the WG work on the document. - The work can be done in the IETF, and the author agrees. The author should (IMHO) be the one to inform the RFC Editor that he/she is dropping the request to publish outside IETF review. but that seems to drop a ball - the RFC Editor asks the IESG a question imo the IESG should answer - maybe just say 'we are talking with the author about doing this work in the IETF' but at least say something to close the loop I also think that just leaving out these possibilities makes this document an incomplete picture of the processing that goes on and I fail to see a reason to not mention that bringing the work into the IETF is an option (even if you think the author should tell the RFC Editor that is being done) - The work can be done in the IETF (or rather, this draft could be the basis for further work in the IETF), but the author wants it published independently anyway. In this case, I think it is good for the health of the RFC series AND for the time budget of the IESG that the IESG does NOT say should be brought in to the RFC Editor; the IESG, having failed to convince the author, should just live with the RFC Editor's judgment on publication. agree (and 2026 specifically calls this case out) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
--On 11. mai 2004 08:46 -0400 Scott Bradner [EMAIL PROTECTED] wrote: - The work can be done in the IETF, and the author agrees. The author should (IMHO) be the one to inform the RFC Editor that he/she is dropping the request to publish outside IETF review. but that seems to drop a ball - the RFC Editor asks the IESG a question imo the IESG should answer - maybe just say 'we are talking with the author about doing this work in the IETF' but at least say something to close the loop Yes - the IESG should answer. But I believe the question being asked is is there a reason, based on conflict with existing IETF work, that this document should not be published? And the IESG should answer yes or no to that question. Anything else should (IMHO) be advice to the RFC Editor and the author, and not be part of the formal position-taking the IESG makes. Because in the past, we've seriously bogged down independent publications because we were debating (with or without the author) whether or not they should be IETF work. And we need to stop doing that. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
Anything else should (IMHO) be advice to the RFC Editor and the author, and not be part of the formal position-taking the IESG makes. we may be debating termonology your ID says The IESG may return five different responses that seems to eliminate the possibility of communicating any such advice Because in the past, we've seriously bogged down independent publications because we were debating (with or without the author) whether or not they should be IETF work. And we need to stop doing that. beware of tossing too much away just to stop doing that I still fail to see why this document cannot say that one of the outcomes could be that the author could agree with the IESG to bring the work into the IETF - it seems a bit dogmatic to refuse to say that (and counter to the intent of 2026) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Not sure if this is the right place for this
At 2:18 AM -0500 5/11/04, Eric A. Hall wrote: I'm not even sure they are similar arguments. I mean, the argument against SSL is that *if* an SSL connection is blocked, and *if* an alternative clear channel exists, and *if* that channel accepts clear-text logins, and *if* the client fallsback through all of that, then the session will be exposed. I'll grant that it's easy enough to interfere with somebody establishing a session, and that there's a measurable percentage of services that maintain clear channel alternatives, and that PLAIN/LOGIN are still the only things that work everywhere, and that there are probably clients which fallback invisibly. I can also argue some of those points to some degree -- that people who have setup SSL versions are likely to have eliminated access to the clear channel, for example -- so instead of any of those things being certainties, we should agree that this is a question of overlapping probabilities. Not only can you argue that, it is the default setting for most SSL-using applications today (other than web browsers). As we were discussing this years ago, most application developers thought that this arrangement is exactly what the users wanted. On the other hand, STARTTLS *requires* a clear channel that the client MUST *already* be using. So whereas the attack on SSL *might* succeed in putting the client in touch with an unencrypted service, TLS is *guaranteed* to be using such a service already anyway. The only question is whether or not a decipherable login can be used, which is a probability mask that also applies to the SSL scenario. Exactly right. This is the strongest argument in favor of protected ports over STARTTLS. Given the collection of probabilities, therefore, starting with an SSL channel and refusing connections to a backup clear channel eliminates most of the probability from the MitM attack model. Right. And this is rejected by most people as unreasonable for the application users, unfortunately. What we are battling here is not how to do the protocols securely, but how to get the users to use the applications securely. If they say if I can't get a secure connection I still want to communicate, all our lovely design is lost. I don't think it really matters given the other problems (see below). Fully agree. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
Scott, Harald, It seems to me that this problem/ disagreement could be easily solved while preserving the (IMO, valid) points both of you are making, by including a sentence somewhere to the effect of... Of course, the IESG or individual ADs may have discussions with the author during this period about other possible ways to handle the document. Should that discussion result in a voluntary action by the author to drop the request to the RFC Editor to publist, the document moves immediately outside the scope of this specification. Now, that may not be the right phrasing in context, and can certainly be improved. But I think it covers the full range of from we really think this should be standardized, why not let us process it that way to if you insist on publishing that thing, I'm going to break both of your legs. The question of whether those actions are appropriate is a separate issue, but the IESG has never been able to insist on either standardization or withdrawal. And, as far as I know, both actions are identical as far as the RFC Editor is concerned: the document is spontaneously withdrawn as an individual submission. john --On Tuesday, May 11, 2004 9:57 AM -0400 Scott Bradner [EMAIL PROTECTED] wrote: Anything else should (IMHO) be advice to the RFC Editor and the author, and not be part of the formal position-taking the IESG makes. we may be debating termonology your ID says The IESG may return five different responses that seems to eliminate the possibility of communicating any such advice Because in the past, we've seriously bogged down independent publications because we were debating (with or without the author) whether or not they should be IETF work. And we need to stop doing that. beware of tossing too much away just to stop doing that I still fail to see why this document cannot say that one of the outcomes could be that the author could agree with the IESG to bring the work into the IETF - it seems a bit dogmatic to refuse to say that (and counter to the intent of 2026) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
in general that seems OK though I'd like to see including the possibility of the author pursuing the work within the IETF added From [EMAIL PROTECTED] Tue May 11 12:18:30 2004 X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Date: Tue, 11 May 2004 12:18:20 -0400 From: John C Klensin [EMAIL PROTECTED] To: Scott Bradner [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] X-Mailer: Mulberry/3.1.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Scott, Harald, It seems to me that this problem/ disagreement could be easily solved while preserving the (IMO, valid) points both of you are making, by including a sentence somewhere to the effect of... Of course, the IESG or individual ADs may have discussions with the author during this period about other possible ways to handle the document. Should that discussion result in a voluntary action by the author to drop the request to the RFC Editor to publist, the document moves immediately outside the scope of this specification. Now, that may not be the right phrasing in context, and can certainly be improved. But I think it covers the full range of from we really think this should be standardized, why not let us process it that way to if you insist on publishing that thing, I'm going to break both of your legs. The question of whether those actions are appropriate is a separate issue, but the IESG has never been able to insist on either standardization or withdrawal. And, as far as I know, both actions are identical as far as the RFC Editor is concerned: the document is spontaneously withdrawn as an individual submission. john --On Tuesday, May 11, 2004 9:57 AM -0400 Scott Bradner [EMAIL PROTECTED] wrote: Anything else should (IMHO) be advice to the RFC Editor and the author, and not be part of the formal position-taking the IESG makes. we may be debating termonology your ID says The IESG may return five different responses that seems to eliminate the possibility of communicating any such advice Because in the past, we've seriously bogged down independent publications because we were debating (with or without the author) whether or not they should be IETF work. And we need to stop doing that. beware of tossing too much away just to stop doing that I still fail to see why this document cannot say that one of the outcomes could be that the author could agree with the IESG to bring the work into the IETF - it seems a bit dogmatic to refuse to say that (and counter to the intent of 2026) Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
On Mon, 10 May 2004, Harald Tveit Alvestrand wrote: Dean, third time same complaint, third time same answer. No. A WG chair is expected to read mail coming from the working group list. What he does with copies that go directly to him is his own business. I disagree. A WG chair has to read email from participants, including off-list email. Certain complaints and business needs to be handled off-list. And as I have told you on the previous two instances of this complaint: Personal mail to you, including bounce messages, is not someone defaming you in the IETF, even when you choose to make it public. I disagree, and I believe the IETF attorney has advised you otherwise. The previous complaints involving Paul Vixie and Joe Abley regarded their roles as participants, not as representatives of the IETF. Dean Anderson Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
The following message indicates that EP.NET has assigned an IP address to ISC.ORG. You are quite well aware of this. Dissembling will not help you. --Dean Date: Thu, 15 Jan 2004 10:26:42 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: bill [EMAIL PROTECTED] Subject: Re: Complaint regarding www.sorbs.net (204.152.186.189) (fwd) On Wed, 14 Jan 2004, bill wrote: I have no reason to act as your relay agent. We have no agreement in place for me to act in this manner. The traceroute I forwarded shows that your IP addresses 198.32.176.4 is assigned to ISC.ORG, which typically indicates a relationship. 8 paix-gw4.isc.org (198.32.176.4) 92.828 ms 91.036 ms 91.415 ms On Mon, 10 May 2004 [EMAIL PROTECTED] wrote: but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET (ISC.ORG upstream) says he has no contract with me to accept complaints about ISC.ORG. --Dean Dean... you are asserting a relationship that you have no way to prove exists. Unless or until you can prove that ep.net is an upstream for isc.org, please refrain from making such statements. Traceroute is not your friend in this case. Defamation works many ways. --bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
On Mon, 10 May 2004, Noel Chiappa wrote: So? Rob's not refusing to accept *any* email *at all* from you as a person (just from a range of addresses which are generating email he doesn't like); and you're more than savvy enough technically to get email to him via some other path. As an IETF WG chair, he's obligated to follow the IETF rules on public participation. He can't block anything that the IETF mail server can't block: Public Participants. He's not under any more obligation to accept email from you via whatever channel you feel like using, no matter how onerous for him, than he is to accept messages written on 12' long oak logs of 3' diameter. Get a life, will you? Your constant whining and flaming is really getting old. You're getting really close to the line at which I'd ask the Chair to ban you from posting. Oh wait, I know what your response would be - you'd sue us. And you seem to think the rest of the world is doing things which is making you look bad. Here's another free clue: you're doing a far better job of that than the rest of us could do with a decade of free time. I'm entitled to particpate, and I'm entitled to send email to the WG chairs as a participant. One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. Dean Anderson Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Dean Anderson wrote: One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. No, actually, that's very difficult for anyone to see. First off there's the simple matter that hijacked doesn't mean you hijacked it; as has already been pointed out, it could mean that someone else hijacked part of it from you. Second there's the fact that ARIN lists your netblock as being assigned to the Open Software Foundation (with yourself as the contact). It is impossible for an outsider to know whether or not the OSF transferred the block to av8.com legitimately. I don't suspect it, you understand--nor do I much care--I'm just pointing out that it's not plain whether anybody here is lying. -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |Baldric, how did you manage to find a turnip that cost 400,000| |pounds? Well, I had to haggle. --Blackadder III | \===/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaint on abuse of DNSOP lists
Dean, ok, i asked nicely and privately several times. PLEASE! take this thread some place else. -rick On Tue, 11 May 2004, Dean Anderson wrote: On Mon, 10 May 2004, Noel Chiappa wrote: So? Rob's not refusing to accept *any* email *at all* from you as a person (just from a range of addresses which are generating email he doesn't like); and you're more than savvy enough technically to get email to him via some other path. As an IETF WG chair, he's obligated to follow the IETF rules on public participation. He can't block anything that the IETF mail server can't block: Public Participants. He's not under any more obligation to accept email from you via whatever channel you feel like using, no matter how onerous for him, than he is to accept messages written on 12' long oak logs of 3' diameter. Get a life, will you? Your constant whining and flaming is really getting old. You're getting really close to the line at which I'd ask the Chair to ban you from posting. Oh wait, I know what your response would be - you'd sue us. And you seem to think the rest of the world is doing things which is making you look bad. Here's another free clue: you're doing a far better job of that than the rest of us could do with a decade of free time. I'm entitled to particpate, and I'm entitled to send email to the WG chairs as a participant. One thing I've noticed is that of none of the people criticizing me has thought to address the fact that OUR ADDRESS SPACE IS NOT HIJACKED, and that these people associated with the IETF: Paul Vixie, Joe Abley, Bill Manning, and Rob Austein as WG Co-chair in his role for IETF business, all claim that it is. But anyone can plainly see they are lying. Dean Anderson Av8 Internet, Inc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Complaint on abuse of DNSOP lists
I can't parse your statement. I didn't say assignment of IP space __impunes__ a service. Perhaps you meant to say that your assignment of IP address space to abusers doesn't impune the rest of your services. This was the claim made by Media3 in Media3 v. MAPS. Media3 lost. But assignment of IP address space does indicate a relationship. Your denials of that relationship are frivolous. Now, as in January, a close read of your message reveals that you didn't actually _deny_ the relationship, you tried to convince me that there was no _proof_ of any relationship. With regard to spam, we call such deniable relationships pink contracts. The spam-hoster tries to deny that anyone has any proof there is a relationship with the spammer. I'd love to be able to say you were violating you AUP, but you don't have one published. Indeed, it is rather interesting that neither EP.NET (Bill Manning), nor ISC.ORG (Paul Vixie) had published AUPs. But as Media3 V. MAPS demonstrated, we can call a spade a spade. You host abusers, we can call you abuse-friendly. I suspect this is off-topic from the subject of abuse on DNSOP lists. I would like to redirect anyone who would like to continue this offlist. I will shortly put all of your January emails and you current emails regarding EP.NET and ISC.ORG on the web under IADL.ORG (Internet Anti-Defamation League). --Dean On Tue, 11 May 2004 [EMAIL PROTECTED] wrote: assignment of IP space does not impune any other service. Asserting otherwise is foolish. Pressing the point, esp. in public fora, appears to be willful ignorance. Please enjoy your blissful state. --bill On Tue, May 11, 2004 at 02:02:45PM -0400, Dean Anderson wrote: The following message indicates that EP.NET has assigned an IP address to ISC.ORG. You are quite well aware of this. Dissembling will not help you. --Dean Date: Thu, 15 Jan 2004 10:26:42 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: bill [EMAIL PROTECTED] Subject: Re: Complaint regarding www.sorbs.net (204.152.186.189) (fwd) On Wed, 14 Jan 2004, bill wrote: I have no reason to act as your relay agent. We have no agreement in place for me to act in this manner. The traceroute I forwarded shows that your IP addresses 198.32.176.4 is assigned to ISC.ORG, which typically indicates a relationship. 8 paix-gw4.isc.org (198.32.176.4) 92.828 ms 91.036 ms 91.415 ms On Mon, 10 May 2004 [EMAIL PROTECTED] wrote: but ISC.ORG doesn't want to take a complaint. Bill Manning, of EP.NET (ISC.ORG upstream) says he has no contract with me to accept complaints about ISC.ORG. --Dean Dean... you are asserting a relationship that you have no way to prove exists. Unless or until you can prove that ep.net is an upstream for isc.org, please refrain from making such statements. Traceroute is not your friend in this case. Defamation works many ways. --bill ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Application Aspects of IPv6 Transition' to Informational RFC
The IESG has received a request from the IPv6 Operations WG to consider the following document: - 'Application Aspects of IPv6 Transition ' draft-ietf-v6ops-application-transition-02.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. The IESG is interested in IETF wide review for this document since it covers other areas than just Operations Management. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-02.t xt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
