Re: uncooperative DNSBLs, was several messages
Given that the well known DNSBL causing me grief totally ignores my requests for removal, ... I'd be interested in knowing what DNSBL it is. Spamhaus PBL? MAPS/Trend DUL? SORBS? Something else? All the anonymous denunciations here are getting a bit tedious. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
On Thu, 13 Nov 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], Dave CROCKER writes: Mark Andrews wrote: In message [EMAIL PROTECTED], Tony Finch writes: SMTP over TLS to an MX does NOT protect against man in the middle attacks. It does when you turn on DNSSEC Perhaps I'm not understanding, but I think you just confirmed that Tony's statement was correct. No. To protect against man-in-the middle you need to know with whom you are supposed to be talking. SMTP over TLS will do that provided you have that knowledge. One way to aquire that knowledge is to use DNSSEC to prevent spoofed MX records. You also need the server to provide a verifiable TLS certificate. The vast majority of them are not. This problem is perhaps even harder to fix than the lack of DNSSEC. http://www.imc.org/ietf-smtp/mail-archive/msg05366.html Another way is to use configuration information. Which is useful for a few select senders and recipients, but doesn't scale to all the external destinations a site might use. You also need to configure you MTA to not use plain SMTP if STARTTLS is not offered by MTA. This can be done globally or on a MTA by MTA basis. Which would mean you can only send email to a vanishingly small number of destinations. Having the ability to signal if the MTA is supposed to offer STARTTLS in the DNS would remove the downgrade attack path, in the general case. Right, there are several improvements of this kind that need to be made to the protocol before it can provide widespread security without explicit per-recipient configuration at every sending site. ESMTP STARTTLS has its place - it works OK for message submission - but I think we need something different for TLS to MXs. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ SOUTHEAST ICELAND: SOUTHWESTERLY VEERING NORTHEASTERLY, 5 TO 7, VEERING SOUTHWESTERLY IN FAR SOUTH LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
--On Wednesday, 12 November, 2008 23:46 -0500 Al Iverson [EMAIL PROTECTED] wrote: ... The professional who has printed their AOL.com email address on their business card has problems that are far greater than, and not unique to, an ISP's use of DNSBLs. And yet, Al, it is fairly regularly done. And yahoo.com addresses are even more common -- a usage that, at least at one time, Yahoo actively encouraged for those who were maintaining stores there. I also see mac.com and gmail.com email addresses on business cards fairly regularly. Now, if people ask me for advice, I tell them that they are better off with their own domains and with associated Whois info that points directly to their businesses (no anonymous or hidden registration stuff). But only a tiny percentage ask me. Assuming one of these professional has decided, even by default, to do that, where is it written that they have problems sufficiently severe that you get to decide that they really are not entitled to reliable email? You should also be aware, in case you are not, that in many parts of the world (and even the US) the choice of ISPs for a residential customer is essentially limited to one. And that ISP, based on how they have interpreted advice from the antispam community, has tried to block outbound SMTP connections that go anywhere but to their servers. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats - limitations of 6to4
On Thu, 13 Nov 2008, Rémi Després wrote: If an implementation implements RFC3484 and the user is not using custom address selection policy, all compliant RFC3484 implementations should prefer v4 when connecting to native from 6to4 (rule 5 of destination address selection AFAIR). Actually, my above statement is incomplete. Thanks for your eagle eyes :-) In case the user has a RFC1918 IPv4 address and the destination is global v4 address, you'd use 6to4. In case IPv4 address is global and destination is global, or both are RFC1918, you would use IPv4. As such: Can we derive from this that Google's IPv6 address is necessarily 6to4 (most of its US customers using it are 6to4), and that Google has therefore a guaranteed path toward other 6to4 hosts? I believe Google is using native addresses. The 6to4 hits are probably caused by the users with private v4 addresses or users whose implementation does not support rfc3484. Besides, isn't this a strong reason in favor of native IPv6 (albeit like Free did it with 6rd on its IPv4 infrastructure) vs 6to4? Native is in many cases better than 6to4 or Teredo (but in some cases 6to4 - 6to4 is better than native). But this is something I specifically didn't comment on in my mail. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
On Wed, 12 Nov 2008, Iljitsch van Beijnum wrote: In my opinion, this is a bug. This is the default policy table from a FreeBSD system, which is the RFC 3484 table IIRC: You should probably bring this up on 6MAN WG list then. ip6addrctl Prefix Prec Label Use : : 1/128 50 00 : :/0 40 1 646064 2002::/16 30 20 : :/96 20 30 : : :0.0.0.0/96 10 40 The last line catches IPv4. It's two steps below the 6to4 prefix. However, the fact that the label for the 6to4 prefix doesn't match the ::/0 label means that IPv4 will be used. This happens on FreeBSD and XP, and I assume also on Vista. But not on MacOS, because it doesn't implement the policy table. I don't know about Linux. (If you want to test, try to connect to 6to4test.runningipv6.net and see what happens. Both addresses are unreachable, though.) I'm not sure whether you're agreeing with me or something else; I don't see where you're saying the bug is. But if we start talking about issues in RFC3484, it should happen on 6MAN list. Your test is inconclusive due to the fact that the A record is a private address. Depending on whether the connecting host has a global or private address, the results are different (see my mail to Remi for more). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
Eric Klein wrote: Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. I agree, and it is not behave's place to make that decision at this time. I had originally proposed that this be discussed in int-area (if nothing else because behave's plate is rather full), but some folks pointed out that some modes may have affects on applications and that behave was best able to determine that, particularly within context of the other NATxy work. I'm looking forward to that assessment. So for now this should remain discussion to understand the problem space and potential solution space better, not a final referendum on whether or not the IETF is going to charter work in or otherwise endorse NAT66 in any manner. Thanks, - Mark Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely discussion of the topic. - Mark Margaret Wasserman wrote: Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Cross posted to several lists Can we keep the NAT66 discussion to less than WGs at a time? I am trying to keep up with multiple threads on this and trying to explain that we do not have a valid requirement for NAT66 defined on any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). Le's get this to one group (maybe we need a new mailing list just for NAT66 discussions, but this is getting out of hand. Until now the simple response is that the IETF does not support NAT in the v6 architecture. If this needs changing lets do it right with proper gap analysis and needs assessment, and then seeing if there is a solution (several have been proposed that are not NAT) or if we need to create one, and if those fail then see about changing the architecture of IPv6. Eric ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
John Levine in [EMAIL PROTECTED]: David Morris in [EMAIL PROTECTED]: Given that the well known DNSBL causing me grief totally ignores my requests for removal, ... I'd be interested in knowing what DNSBL it is. Received: from email.xpasc.com (email.xpasc.com [65.85.17.142]) by core3.amsl.com (Postfix) with ESMTP id 2CAE63A6782 for ietf@ietf.org; Wed, 12 Nov 2008 20:09:01 -0800 (PST) | dig any 142.17.85.65.dnsbl.sorbs.net +short | 127.0.0.10 | Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?65.85.17.142; Certainly looks to be listed incorrectly ... | dig -x 65.85.17.142 +short | email.xpasc.com. | dig a email.xpasc.com +short | 65.85.17.142 | whois -h whois.geektools.com 65.85.17.142 | OrgName:MegaPath Networks Inc. | ReferralServer: rwhois://rwhois.megapath.net:4321/ | nc rwhois.megapath.net 4321 | %rwhois V-1.5:003eff:00 siberia.megapath.net | 65.85.17.142 | network:ID:NET-65.85.17.128/28 | network:Organization;I:BARILI SYSTEMS LIMITED | whois -h whois.geektools.com xpasc.com | Administrative Contact, Technical Contact: | Morris, David W | Barili Systems Limited That seems to satisfy all the requirements for removal listed at http://www.us.sorbs.net/faq/dul.shtml -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] P2PSIP diagnostics: PING discussion
Hi, I am not sure what you mean NTP refresh, if the test was using the system clock than you would expect in XP that it will be updated every tick which is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC 3550) for synchronization and the RTP time is using the system clock which may add skew but it is not because of NTP. Roni Even From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 11:31 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion Hi Song, Even in the planetlab testbed, the following paper at PAM 2008 ( http://pam2008.cs.wpi.edu/slides/pathak.ppt ) shows that more than 40% of nodes have more than 20ms NTP error. In a general overlay we are likely to find a larger fraction of nodes with error in their NTP time (since the planetlab testbed is managed by the people who own the machines while general overlay nodes are unlikely to be that well maintained). Unless NTP refresh is made mandatory within a p2psip implementation, relying on ntp would be unlikely to be helpful to diagnostics Thanks Saumitra www.saumitra.info === Dear all, In P2PSIP base protocol, Ping is used to test connectivity along a path. However, connectivity quality can not be measured well without some useful information, such as the timestamp and HopCounter. In p2psip diagnostics draft version 03 http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt we extend the Ping message payloads with a few kinds of useful information for connectivity quality check purposes. The initiator node receiving the Ping response should compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops. About the Timestamp, we are not sure if the NTP time is a good candidate for it, or we have other ways to describe it, or we don't need the timestamp at all. But if NTP time is used in the overlay, then it is a good choice, because every peer along the message path will know when the message is generated, and it is easy for the peer along the path to calculate the message latency. However many overlays may not be synchronized with the NTP time. Any comments? Best Regards, Song Haibin Email: melodysong at huawei.com Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] How to describe the processing power
Song Haibin, Your response It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. does also address Bruce question. My view is that the pure CPU power or CPU current usage are good but the question is if they are relevant for the decision since the user may limit the amount of resources it wants to allocate for the p2p application. This may be based on percentage from the link or number of connections. Roni Even From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Song Haibin Sent: Thursday, November 13, 2008 5:07 AM To: 'Das, Saumitra'; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Das, See inline. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:12 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Song, Processing power would be more informational in terms of CPU load. A good example of what would be useful would be to look at the comon monitoring tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It uses the following metrics for selecting nodes based on CPU and I have found such selection to be very useful in determining the performance of a slice on the machine. [Song] It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. From the comon site, these are some metrics that may be useful CPU Speed Busy CPU Sys CPU Free CPU These fields give some insight into the CPU behavior of the node. The CPU Speed is just the speed of the processor in gigahertz. The Busy CPU field gives the % of time the CPU is utilized, and the Sys CPU field specifies what percentage of time the CPU is spending in the OS. Both of these values are the maximum values over the past 5 minutes. The Free CPU indicates how much of the CPU a spin-loop was able to obtain, giving some insight into how much of the node's CPU a new slice would receive. We could define these fields and leave it optional as to whether all of them are required. i.e. running a spin-loop may be expensive for some devices. [Song] This is helpful. I'm very glad to see this monitoring tool in the planetlab testbed. If it works well in the planet lab, we may have it included in the diagnostics draft after discussion. I also see other useful metrics for other parameters in the page (http://summer.cs.princeton.edu/status/). Best, Saumitra www.saumitra.info Date: Tue, 11 Nov 2008 15:12:21 +0800 From: Song Haibin [EMAIL PROTECTED] Subject: [P2PSIP] How to describe the processing power To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Dear all, In p2psip diagnostics draft http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt , we have some doubt about how to describe one of the diagnostic information: processing power. We propose to use the unit of MIPS to describe it. However, the Max number of connections may be another choice. Do you have any good suggestions? Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
On Thu, Nov 13, 2008 at 8:47 AM, John C Klensin [EMAIL PROTECTED] wrote: --On Wednesday, 12 November, 2008 23:46 -0500 Al Iverson [EMAIL PROTECTED] wrote: ... The professional who has printed their AOL.com email address on their business card has problems that are far greater than, and not unique to, an ISP's use of DNSBLs. And yet, Al, it is fairly regularly done. And yahoo.com addresses are even more common -- a usage that, at least at one time, Yahoo actively encouraged for those who were maintaining stores there. I also see mac.com and gmail.com email addresses on business cards fairly regularly. John, I'm sorry you misunderstand. I was already well aware that some people use an ISP email address on printed materials. Maybe they paint it on their van down by the river. Just like with a phone number. That doesn't negate the fact that there is ample evidence that recipients will jump ship on an ISP when they can't get desired mail. Again, working for an ESP, this is a scenario that I deal with regularly. Both scenarios exist, clearly. I don't agree that it's hard to change ISPs (or set up a second mailbox to route around an inbound delivery issue), but I grant that it is non-trivial for many. Ultimately, though, I need a better understand here. Not getting it from what's been said so far. What's the point? If the point is that DNSBLs should be more accountable, and we should work toward a world where spam filtering usage, usage of DNSBLs, can be configured on a per-user basis, and a user has an easy method of opting in or opting out, then I'm in full agreement. But that's not where the world is today, and it's unreasonable to expect it to be written into a specification that will then be ignored. If that isn't your point, then I must humbly admit that I don't understand and I await further insight. Regards, Al -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: several messages
This is a somewhat silly discussion, pretty much the ONLY real reason to use your own domain rather than a gmail or aol or whatever is precisely the fact that switching costs are high. And the real problem is not gmail.com but comcast.net. If access to the email address requires continuation of an ISP service the switching cost issue bcomes a very real problem. Even more so if the ISP decides to rename itself - as mine has three times. From: [EMAIL PROTECTED] on behalf of David Morris Sent: Thu 11/13/2008 12:02 AM To: Al Iverson Cc: ietf@ietf.org Subject: Re: several messages On Wed, 12 Nov 2008, Al Iverson wrote: On Wed, Nov 12, 2008 at 11:37 PM, David Morris [EMAIL PROTECTED] wrote: On Wed, 12 Nov 2008, Al Iverson wrote: On Wed, Nov 12, 2008 at 11:08 PM, David Morris [EMAIL PROTECTED] wrote: In the end, walking isn't a viable alternative. Because it's so hard to open a Gmail account? I think your thinking here is about two generations out of date. Back in 1995 when we each had our one dialup account, and webmail was much less common and acceptable, your point would have been more valid. C'mon ... my example contractor has printed collateral, web pages, etc. all with his email address. Changing an email address is non-trivial for folks who don't have any need to register their own domain name. Even those who have a web serving domain often have no business need for email. The professional who has printed their AOL.com email address on their business card has problems that are far greater than, and not unique to, an ISP's use of DNSBLs. I never said they used aol.com ... only that it was a major ISP. Both that ISP and aol *HAVE* worked to deal with issues I've had. Other ISPs have not. It was still a waste of my time. My point is that it is difficult to change email addresses because there are lots of references which have value. Business cards are one example. All other business printed materials are another. Every customer's mail folders are another. Simply walking from an ISP isn't an easy choice. This is particularily true for folks for home computer technology is simply a tool they use to communicate. This general issue is well enough understood that the FCC forced phone companies and cellular carriers to provide number portability to insure folks with an investment in their phone number could take advantage of competition. Dave Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Can we have on NAT66 discussion?
I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. If you want to effect a transition from IPv4 to IPv6, the only way to do that effectively is to design a protocol stack in which the applications simply do not care whether their packets are routed over IPv4, IPv6 or carrier pidgeon. NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts. I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed. On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it. And yes, I have been guilty of many of the same mistakes. But unlike some folk I am not about to compound that mistake by telling the folk who want NAT66 that they should visit a re-education camp and unlearn their heretical thoughts. The only reason NAT is bad in practice is because some people were so opposed to the concept that they decided it would be a good thing to allow designs that were purposefully designed to be NAT-unfriendly. If we don't want to have these discussions on the IETF list we should have a separate architecture list. NAT66 is a reasonable protocol proposal to make. If BEHAVE does not like the idea let the advocates start a new group. From: [EMAIL PROTECTED] on behalf of Mark Townsley Sent: Thu 11/13/2008 9:10 AM To: Eric Klein Cc: Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? Eric Klein wrote: Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. I agree, and it is not behave's place to make that decision at this time. I had originally proposed that this be discussed in int-area (if nothing else because behave's plate is rather full), but some folks pointed out that some modes may have affects on applications and that behave was best able to determine that, particularly within context of the other NATxy work. I'm looking forward to that assessment. So for now this should remain discussion to understand the problem space and potential solution space better, not a final referendum on whether or not the IETF is going to charter work in or otherwise endorse NAT66 in any manner. Thanks, - Mark Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely discussion of the topic. - Mark Margaret Wasserman wrote: Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Cross posted to several lists Can we keep the NAT66 discussion to less than WGs at a time? I am trying to keep up with multiple threads on this and trying to explain that we do not have a
Re: uncooperative DNSBLs, was several messages
Given that the well known DNSBL causing me grief totally ignores my requests for removal, ... I'd be interested in knowing what DNSBL it is. Received: from email.xpasc.com (email.xpasc.com [65.85.17.142]) by core3.amsl.com (Postfix) with ESMTP id 2CAE63A6782 for ietf@ietf.org; Wed, 12 Nov 2008 20:09:01 -0800 (PST) | dig any 142.17.85.65.dnsbl.sorbs.net +short | 127.0.0.10 | Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?65.85.17.142; Certainly looks to be listed incorrectly ... From time to time, I stumble upon an incorrect SORBS DUL entry when editing dnswl.org entries. A short ticket later, things are usually fixed. -- Matthias ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl(DNS Blacklists and Whitelists))
Who cares about the use measurement? I care about the proportion of the Internet where I can obtain acceptable service with full functionality via an IPv6-only endpoint connection. From: [EMAIL PROTECTED] on behalf of David Kessens Sent: Wed 11/12/2008 4:28 PM To: Joe St Sauver Cc: ietf@ietf.org Subject: Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl(DNS Blacklists and Whitelists)) Joe, On Tue, Nov 11, 2008 at 03:12:53PM -0800, Joe St Sauver wrote: David mentioned: On the other hand, just to put this in context and to pick on an application I'm somewhat familiar with, a single full-ish Usenet news feed is now in excess of 3TByte/day (see the daily volume stats quoted at http://en.wikipedia.org/wiki/Usenet ). Just two or three full-ish Usenet News feeds over IPv6, if done across AMS-IX, would account for most of that 800Mbps traffic load (assuming that Usenet is what was making up most of that traffic, an assertion that I'm explictly NOT making). My point? It is possible that the IP transport choices of just a few cooperating server administrators might (at least hypothetically) account for virtually all the observed growth in AMS-IX IPv6 traffic. Very good analysis: rumor has it that a large part of the AMS-IX traffic is indeed usenet traffic. However, that doesn't mean that it is not real IPv6 traffic: eg. we don't decide not to count IPv4 Usenet traffic either. On the other hand, this graph only shows native traffic so there is most likely more than what is visible in the graph. However, there are quite a few other observations by others (also mentioned on this list) that put the total amount of IPv6 traffic to various other parts of the Internet at a bit more but in the same order of magnitude so it doesn't seem that the AMS-IX data is out of line (various presentations on this topic from the last RIPE meeting are available on rosie.ripe.net, look for ipv6 working group or plenary). So to bring this post to a close, I continue to believe that IPv6 traffic, at least IPv6 email traffic, remains very, very low, to the point where, as I've previous mentioned, it just hasn't justified DNS block list operator attention in any material way (love to hear about any counter examples, BTW). This of course depends a bit on what you define as very, very low. However, I can certainly see that it is not enough to get the attention of a DNS block list operator. I do do know however, that I received my first spam mail over IPv6 several years ago. The reason for my mail was not to disproof your point but to put the arbornetworks numbers in a bit more perspective. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, Nov 13, 2008 at 6:23 AM, John Levine [EMAIL PROTECTED] wrote: Given that the well known DNSBL causing me grief totally ignores my requests for removal, ... I'd be interested in knowing what DNSBL it is. Spamhaus PBL? MAPS/Trend DUL? SORBS? Something else? All the anonymous denunciations here are getting a bit tedious. I think anonymous may be a bit better in this context, because otherwise the conversation degenerates into an argument about some particular DNSBL, instead of a discussion about DNSBLs in general. I think a lot of us had a pretty good idea which DNSBL is usually the one in question when people are complaining Al -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
At 08:19 10-11-2008, Russ Housley wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? In a different message, John mentioned has concluded. That sounds better as the numbered items are about conclusions reached. My second preference would be The IESG believes. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: several messages
There is no doubt that email addresses are indeed sticky for most people. However as someone who works for a mid to large ISP, I can say with confidence that using 'reputable' DNSBL's save money for the ISP and the customer as well. To give an example; previous to our Spamhaus deployment we were processing over 90M msg per day. After deploying SBL alone that dropped to 10M! This resulted in not having to buy hundreds of servers and terabytes of disk. If we had not implemented DNSBLs we would have to raise our costs to the subscriber to cover the capital expenditure. Our FP complaints from our subscribers was less than 10 calls in the first six months. After modifying our DSN's to provide clear language to senders why we did not accept their message, and giving them a link to resolve the issue on their own, the complaints from customers disappeared. So yes, you will always have someone that will be affected. It is my belief (solely) that mail system managers need to take responsibility for what flows through their systems. If your users are not doing their due diligence to keep their PCs from becoming zombies, you as the system manager need to protect your systems, so you can ensure that everyone can use them. My $.02 Regards, Anthony On Thu, 13 Nov 2008 06:43:17 -0800, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: This is a somewhat silly discussion, pretty much the ONLY real reason to use your own domain rather than a gmail or aol or whatever is precisely the fact that switching costs are high. And the real problem is not gmail.com but comcast.net. If access to the email address requires continuation of an ISP service the switching cost issue bcomes a very real problem. Even more so if the ISP decides to rename itself - as mine has three times. From: [EMAIL PROTECTED] on behalf of David Morris Sent: Thu 11/13/2008 12:02 AM To: Al Iverson Cc: ietf@ietf.org Subject: Re: several messages On Wed, 12 Nov 2008, Al Iverson wrote: On Wed, Nov 12, 2008 at 11:37 PM, David Morris [EMAIL PROTECTED] wrote: On Wed, 12 Nov 2008, Al Iverson wrote: On Wed, Nov 12, 2008 at 11:08 PM, David Morris [EMAIL PROTECTED] wrote: In the end, walking isn't a viable alternative. Because it's so hard to open a Gmail account? I think your thinking here is about two generations out of date. Back in 1995 when we each had our one dialup account, and webmail was much less common and acceptable, your point would have been more valid. C'mon ... my example contractor has printed collateral, web pages, etc. all with his email address. Changing an email address is non-trivial for folks who don't have any need to register their own domain name. Even those who have a web serving domain often have no business need for email. The professional who has printed their AOL.com email address on their business card has problems that are far greater than, and not unique to, an ISP's use of DNSBLs. I never said they used aol.com ... only that it was a major ISP. Both that ISP and aol *HAVE* worked to deal with issues I've had. Other ISPs have not. It was still a waste of my time. My point is that it is difficult to change email addresses because there are lots of references which have value. Business cards are one example. All other business printed materials are another. Every customer's mail folders are another. Simply walking from an ISP isn't an easy choice. This is particularily true for folks for home computer technology is simply a tool they use to communicate. This general issue is well enough understood that the FCC forced phone companies and cellular carriers to provide number portability to insure folks with an investment in their phone number could take advantage of competition. Dave Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Al Iverson wrote: I think anonymous may be a bit better in this context, because otherwise the conversation degenerates into an argument about some particular DNSBL, instead of a discussion about DNSBLs in general. I think a lot of us had a pretty good idea which DNSBL is usually the one in question when people are complaining The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. For any interesting capability, there will always be some bad actors using it. So the argument that, therefore, the capability is unworthy of standardization is problematic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
It _does_ mean that someone to whom email is important had better do due diligence in selecting DNSBLs - just as someone to whom a car is important had better do due diligence in selecting a mechanic [...] I agree with that. But easier still is to setup your own spam traps and run your own spamfilter. Which is what I think most actually do. Not easier for me; not easier for the ISP I work for (I'm part of its collective postmaster). I, at home, and we, at work, find DNSBLs by far the lower-cost answer, after all the costs are tallied (dollars spent, human time, false positives, false negatives, machines, disk space, network bandwidth, the list of forms costs can take is long). Perhaps we're atypical. I've always assumed we're more or less typical, but just on the general grounds that I assume typicality until I find evidence to the contrary. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] P2PSIP diagnostics: PING discussion
Hi Das, The slides you provided are interesting. As for the RTT, we may not need the timestamp. However, from the overlay management perspective, one may want to measure the one way delay from an initiator node to the destination node. Then do you have any suggestions for that? Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:31 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion Hi Song, Even in the planetlab testbed, the following paper at PAM 2008 ( http://pam2008.cs.wpi.edu/slides/pathak.ppt ) shows that more than 40% of nodes have more than 20ms NTP error. In a general overlay we are likely to find a larger fraction of nodes with error in their NTP time (since the planetlab testbed is managed by the people who own the machines while general overlay nodes are unlikely to be that well maintained). Unless NTP refresh is made mandatory within a p2psip implementation, relying on ntp would be unlikely to be helpful to diagnostics Thanks Saumitra www.saumitra.info === Dear all, In P2PSIP base protocol, Ping is used to test connectivity along a path. However, connectivity quality can not be measured well without some useful information, such as the timestamp and HopCounter. In p2psip diagnostics draft version 03 http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt we extend the Ping message payloads with a few kinds of useful information for connectivity quality check purposes. The initiator node receiving the Ping response should compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops. About the Timestamp, we are not sure if the NTP time is a good candidate for it, or we have other ways to describe it, or we don't need the timestamp at all. But if NTP time is used in the overlay, then it is a good choice, because every peer along the message path will know when the message is generated, and it is easy for the peer along the path to calculate the message latency. However many overlays may not be synchronized with the NTP time. Any comments? Best Regards, Song Haibin Email: melodysong at huawei.com Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] How to describe the processing power
Dear Das, See inline. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:12 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Song, Processing power would be more informational in terms of CPU load. A good example of what would be useful would be to look at the comon monitoring tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It uses the following metrics for selecting nodes based on CPU and I have found such selection to be very useful in determining the performance of a slice on the machine. [Song] It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. From the comon site, these are some metrics that may be useful CPU Speed Busy CPU Sys CPU Free CPU These fields give some insight into the CPU behavior of the node. The CPU Speed is just the speed of the processor in gigahertz. The Busy CPU field gives the % of time the CPU is utilized, and the Sys CPU field specifies what percentage of time the CPU is spending in the OS. Both of these values are the maximum values over the past 5 minutes. The Free CPU indicates how much of the CPU a spin-loop was able to obtain, giving some insight into how much of the node's CPU a new slice would receive. We could define these fields and leave it optional as to whether all of them are required. i.e. running a spin-loop may be expensive for some devices. [Song] This is helpful. I'm very glad to see this monitoring tool in the planetlab testbed. If it works well in the planet lab, we may have it included in the diagnostics draft after discussion. I also see other useful metrics for other parameters in the page (http://summer.cs.princeton.edu/status/). Best, Saumitra www.saumitra.info Date: Tue, 11 Nov 2008 15:12:21 +0800 From: Song Haibin [EMAIL PROTECTED] Subject: [P2PSIP] How to describe the processing power To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Dear all, In p2psip diagnostics draft http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt , we have some doubt about how to describe one of the diagnostic information: processing power. We propose to use the unit of MIPS to describe it. However, the Max number of connections may be another choice. Do you have any good suggestions? Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats - limitations of 6to4
Pekka Savola (1-12/1-31/200x) 11/12/08 9:09 PM: If an implementation implements RFC3484 and the user is not using custom address selection policy, all compliant RFC3484 implementations should prefer v4 when connecting to native from 6to4 (rule 5 of destination address selection AFAIR). Can we derive from this that Google's IPv6 address is necessarily 6to4 (most of its US customers using it are 6to4), and that Google has therefore a guaranteed path toward other 6to4 hosts? Besides, isn't this a strong reason in favor of native IPv6 (albeit like Free did it with 6rd on its IPv4 infrastructure) vs 6to4? RD FWIW, in Linux this was changed as the default maybe about 2-3 years ago. I suppose may other operating systems, especially recent ones, also operate in this manner. For Linux, some info is here: http://people.redhat.com/drepper/linux-rfc3484.html This has been discussed on v6ops and ipv6 lists but unfortunately I can't find the threads despite search attempts. Maybe someone else with better memory could provide better references. This is why observing ipv6 traffic on a dual-stack hostname will mostly just in observing those that use native v6 (with Mikael, this was 0.5% of users). Except if the dual stack server, like that of Google, uses different URLs for IPv6and IPv4, right? If you're interested in wider picture of IPv6 penetration, you'll put the content on v6-only hostname (with Mikael, this was reachable by 6% of users). If you want to also cover for Vista users with Teredo, you'd put the content on a site and refer to it using a numeric address instead of a hostname (this would result in even a higher percentage). So, if you're interested in any kind of IPv6 connectivity at all (even 6to4, teredo, ...), at least in some user communities (p2p users), I'm pretty sure IPv6 penetration is already over 10%. At least 6% is already proven by measurements :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely discussion of the topic. - Mark Margaret Wasserman wrote: Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, [EMAIL PROTECTED] wrote: Cross posted to several lists Can we keep the NAT66 discussion to less than WGs at a time? I am trying to keep up with multiple threads on this and trying to explain that we do not have a valid requirement for NAT66 defined on any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). Le's get this to one group (maybe we need a new mailing list just for NAT66 discussions, but this is getting out of hand. Until now the simple response is that the IETF does not support NAT in the v6 architecture. If this needs changing lets do it right with proper gap analysis and needs assessment, and then seeing if there is a solution (several have been proposed that are not NAT) or if we need to create one, and if those fail then see about changing the architecture of IPv6. Eric ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [P2PSIP] How to describe the processing power
There are still a lot of open research questions for metrics like this, but I think it's fine to include something like that in diagnostics. What you really want is something like max messages forwarded per second and then current load as a factor of that, which would factor in both cpu load and network load. But in general, things like that are really hard to compute, which is why what ends up being reported is utilization and maybe capacity if it can be measured. I think the most important characteristic for metrics to be reported via diagnostics is that they be well-defined and possible to measure, so an implementer knows how to measure what is being requested and the user knows what it means. Also need to make sure whatever diagnostics are defined leverage existing stuff whenever possible. A lot of thought has gone into existing stuff through groups like IPPM, so coming up with new ways to measure network performance probably isn't going to be worthwhile. Bruce On Thu, Nov 13, 2008 at 9:34 AM, Roni Even [EMAIL PROTECTED] wrote: Song Haibin, Your response It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. does also address Bruce question. My view is that the pure CPU power or CPU current usage are good but the question is if they are relevant for the decision since the user may limit the amount of resources it wants to allocate for the p2p application. This may be based on percentage from the link or number of connections. Roni Even From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Song Haibin Sent: Thursday, November 13, 2008 5:07 AM To: 'Das, Saumitra'; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Das, See inline. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:12 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Song, Processing power would be more informational in terms of CPU load. A good example of what would be useful would be to look at the comon monitoring tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It uses the following metrics for selecting nodes based on CPU and I have found such selection to be very useful in determining the performance of a slice on the machine. [Song] It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. From the comon site, these are some metrics that may be useful CPU Speed Busy CPU Sys CPU Free CPU These fields give some insight into the CPU behavior of the node. The CPU Speed is just the speed of the processor in gigahertz. The Busy CPU field gives the % of time the CPU is utilized, and the Sys CPU field specifies what percentage of time the CPU is spending in the OS. Both of these values are the maximum values over the past 5 minutes. The Free CPU indicates how much of the CPU a spin-loop was able to obtain, giving some insight into how much of the node's CPU a new slice would receive. We could define these fields and leave it optional as to whether all of them are required. i.e. running a spin-loop may be expensive for some devices. [Song] This is helpful. I'm very glad to see this monitoring tool in the planetlab testbed. If it works well in the planet lab, we may have it included in the diagnostics draft after discussion. I also see other useful metrics for other parameters in the page (http://summer.cs.princeton.edu/status/). Best, Saumitra www.saumitra.info Date: Tue, 11 Nov 2008 15:12:21 +0800 From: Song Haibin [EMAIL PROTECTED] Subject: [P2PSIP] How to describe the processing power To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Dear all, In p2psip diagnostics draft http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt , we have some doubt about how to describe one of the diagnostic information: processing power. We propose to use the unit of MIPS to describe it. However, the Max number of connections may be another choice. Do you have any good suggestions? Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw ___ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote: The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. I think that's not quite fair. My impression is that there is more than one line of argument. Here are some different ones that I have observed in this discussion, some of which seem never to be getting answers. (Or, sometimes, they seem to be getting answers that are counter-arguments the the first. I believe philosophers would call those examples of the straw person fallacy.) 1. Some DNSBLs are bad, therefore all DNSBLs are bad. (The one you note, and which is obviously bogus.) 2. DNSBLs are in themselves bad, because there is no way to guarantee that they won't contain false positives; they are nevertheless possibly useful, but the trade-offs are inadequeately described in the current document. 3. DNSBLs are not in themselves bad, but the implementation of them as described in the current draft (which does describe the current state of the art in DNSBLs) _is_ bad. The current behaviour and the desirable behaviour ought to be separated, and one described while the other is standardized. There are probably other positions I haven't covered here. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. That's not the problem. The issue is location. Once we have established a session then how the packets are labeled for network layer purposes doesn't matter much (modulo security) but how do we get communications set up in the first place? Suppose I want to reach foo. Who do I ask to find a locator for him? Split DNS works fine when there are just two states, inside and outside -- a DNS server can be configured to know how to respond in each case. But if you were to sprinkle NATs all over the Internet there would be no place that could give a confident answer about how I, over here, should name foo in the network layer in order to get a packet to him, and have that answer get to me in the correct form. So it is very important to understand where we think it might be safe to put what kinds of NATs. swb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, 13 Nov 2008, Jim Hill wrote: | dig any 142.17.85.65.dnsbl.sorbs.net +short | 127.0.0.10 | Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?65.85.17.142; Certainly looks to be listed incorrectly ... | dig -x 65.85.17.142 +short | email.xpasc.com. That seems to satisfy all the requirements for removal listed at http://www.us.sorbs.net/faq/dul.shtml I believe that it's listed 'correctly', per that FAQ, for one reason: [EMAIL PROTECTED] mail]$ dig 142.17.85.65.in-addr.arpa ;; QUESTION SECTION: ;142.17.85.65.in-addr.arpa. IN A ;; ANSWER SECTION: 142.17.85.65.in-addr.arpa. 86265 IN CNAME email.xpasc.com. CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs). -- D ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. In RFC 3932, these numbered items (except the first one, which is the same until the modification above) begin The IESG thinks During pre-Last-Call-review, I received feedback that The IESG finds was a better. Now, you propose The IESG believes.I do believe that the current wording is better than the original. I'm willing to change it to something else if there is consensus to do so. What do other reviewers find/think/believe/prefer? In a different message, John mentioned has concluded. That sounds better as the numbered items are about conclusions reached. My second preference would be The IESG believes. I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. 1. The IESG has concluded that there is no conflict between this document and IETF work. 2. The IESG has concluded that this work is related to IETF work done in WG X, but this relationship does not prevent publishing. 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for X and should therefore not be published without IETF review and IESG approval. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
David Romerstein in [EMAIL PROTECTED]: On Thu, 13 Nov 2008, Jim Hill wrote: That seems to satisfy all the requirements for removal listed at http://www.us.sorbs.net/faq/dul.shtml I believe that it's listed 'correctly', per that FAQ, for one reason: [EMAIL PROTECTED] mail]$ dig 142.17.85.65.in-addr.arpa 142.17.85.65.in-addr.arpa. 86265 IN CNAME email.xpasc.com. CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs). There is a delegated ptr-record ... | dig ptr 142.17.85.65.in-addr.arpa | | ;; ANSWER SECTION: | 142.17.85.65.in-addr.arpa. 59754 IN CNAME email.xpasc.com. | email.xpasc.com.59754 IN PTR email.xpasc.com. The ttl seems to be ok as well (ignore the above from my cache). -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
der Mouse wrote: It _does_ mean that someone to whom email is important had better do due diligence in selecting DNSBLs - just as someone to whom a car is important had better do due diligence in selecting a mechanic [...] I agree with that. But easier still is to setup your own spam traps and run your own spamfilter. Which is what I think most actually do. Not easier for me; not easier for the ISP I work for (I'm part of its collective postmaster). I, at home, and we, at work, find DNSBLs by far the lower-cost answer, after all the costs are tallied (dollars spent, human time, false positives, false negatives, machines, disk space, network bandwidth, the list of forms costs can take is long). In today's climate, you have to have very large spamtraps to do an effective job in driving your own filters unless you have an atypical spam load. If you have users that are being hit by BOTnets, your spamtrap has to be in the 100s of thousands of emails per day, if not larger, to be able to derive the right information to tune filters to an effective level. We're a large company, and we've been able to, through our legacy domains and gracious donations to get our traps up to about 10-20M per day. That alone does a pretty good job. But even we, despite how big our traps are and how well they do, get considerable extra effectiveness by using DNSBLs. At least one of these DNSBLS, via mutterings in the woodworks, has spamtraps that are effectively more than 2 orders of magnitude bigger than ours. Yikes. Someone of the size of AOL or Gmail can do the spamtrap game all by themselves - internally, they usually generate source IP reputation lists (however distributed) in addition to other techniques to use that information. But almost everyone smaller needs much more trap than they can realistically construct themselves. Small sites with usually atypical spam loads can often do just fine with very much smaller data sources. It's amazing how much different the spam profile can be at small sites. But they generally don't work nearly as well once scaled up to larger environments with more representative loadings. As one datapoint to show how uneven spam distribution is: we have 45,000 recipients. Fully half of them get virtually no spam at all. If we segregated those people off on their own mail servers, they wouldn't need filtering. Meanwhile, the other half get lots. One poor sod was getting 4,000-16,000 spams/day for the better part of a year - no useable commonality whatsoever in what he was getting nor where it was coming from. The only explanation for that, ironic as it may be, is that he was on lots of IETF mailing lists for a very long time that got scraped over and over again. The only solution - just what got past the filters at 99%+ effectiveness was overwhelming - was for him to change his email address (actually we all did, the company domain name got changed. Not because of this, but it helped anyway, causing a huge discontinuity in spam volumes.). [Most of the high rollers in our spam sweepstakes are long-term IETF mailing list members on the same address... Long-term IEEE list membership is also a big factor.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Andrew Sullivan wrote: On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote: The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. I think that's not quite fair. My impression is that there is more than one line of argument. Here are some different ones that I have observed in this discussion, some of which seem never to be getting answers. (Or, sometimes, they seem to be getting answers that are counter-arguments the the first. I believe philosophers would call those examples of the straw person fallacy.) 1. Some DNSBLs are bad, therefore all DNSBLs are bad. (The one you note, and which is obviously bogus.) Obviously. 2. DNSBLs are in themselves bad, because there is no way to guarantee that they won't contain false positives; they are nevertheless possibly useful, but the trade-offs are inadequeately described in the current document. If all that's missing is a few sentences in the Security Considerations section, I'm sure that we can get somewhere with that, on the other hand, discussion of those types of tradeoffs probably don't belong in this draft, but a BCP. 3. DNSBLs are not in themselves bad, but the implementation of them as described in the current draft (which does describe the current state of the art in DNSBLs) _is_ bad. The current behaviour and the desirable behaviour ought to be separated, and one described while the other is standardized. Behaviour of DNSBL != information transfer protocol. The document at hand only describes the protocol, and should only describe the protocol, and the security considerations should be on the protocol, not the behaviour. Behaviour is better described in another document. Like the BCP I'm supposed to finish the .05 revision on ASAP. [If I can stop following this thread maybe I'll get it finished.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
--On Thursday, 13 November, 2008 08:18 -0800 Dave CROCKER [EMAIL PROTECTED] wrote: I think a lot of us had a pretty good idea which DNSBL is usually the one in question when people are complaining The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. For any interesting capability, there will always be some bad actors using it. So the argument that, therefore, the capability is unworthy of standardization is problematic. No, Dave, the argument is that there is no established standard (sic) of practice that differentiates between badly-operated DNSBLs and well-operated ones and between appropriate and inappropriate applications of those lists. Although perhaps I'm wrong, I assume that no one would make a serious claim that the use or non-use of particular data formats (i.e., the document in question) would be very significant in making that determination. If there were a BCP on the table that would permit us to talk about DNSRBLs that conform and those that don't, rather than about subjective opinions of behaving badly, we would, IMO, be having a rather different discussion. If we were talking about putting together a WG here, I believe that the community would insist on such a BCP as its first output. That would give the community an opportunity to have a serious and focused discussion about criteria for good behavior. Perhaps this topic is so emotional that such a discussion would be impossible, but at least there would be hope. However, if I can summarize the one thing that people with a _very_ broad range of opinions that conclude in don't standardize this document now seem to have in common, it is an objection to standardization of any of this without clear and documented agreements about acceptable practices and careful documentation about the problems and risks that can occur when those practices are not followed (or even if they are). IMO, that generic objection is well within IETF norms. YMMD, of course. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Andrew Sullivan wrote: On Thu, Nov 13, 2008 at 08:18:01AM -0800, Dave CROCKER wrote: The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. I think that's not quite fair. My impression is that there is more than one line of argument. Andrew, Yeah, I should have qualified what I meant: I focused on the anecdotal and ad hominem (ie, personal) line of argument because of its core philosophical and methodological weaknesses and lack of technical basis. is being taken seriously and I don't understand why. Here are some different ones that I have observed in this discussion, some of which seem never to be getting answers. I'm planning to carefully review all the postings and try to summarize them with considerably more diligence than my previous posting. To that end, it could help quite a bit to see what specific questions you see as needing answering by the proponents of the specification. I should note that I've posted a number of follow-up questions to critics and they have mostly been ignored or dismissed. In stark contrast, the recent posting by John Klensin and then yours and Olaf's are clearly based on core principles. That makes it possible to have constructive debates about facts, architecture and operations. 1. Some DNSBLs are bad, therefore all DNSBLs are bad. 2. DNSBLs are in themselves bad, because there is no way to guarantee that they won't contain false positives; 3. DNSBLs are not in themselves bad, but the implementation of them as described in the current draft (which does describe the current state of the art in DNSBLs) _is_ bad. Good summary of critics' concerns, I think. Thanks. If anyone believes there are other perspectives that should be listed, please say so. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
Russ, FWIW, I can live with this formulation. I would still prefer to get rid of harmful... see below. --On Thursday, 13 November, 2008 12:41 -0500 Russ Housley [EMAIL PROTECTED] wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. ... I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. ... 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. I would recommend replacing is potentially harmful with something like could impede the smooth progress of. That eliminates the issue of harm and replaces it with what is actually a slightly weaker condition. Phrases like could potentially disrupt would be roughly equivalent, again without implying that the IETF process is so fragile that the publication of a document could harm it. But, if the IESG is ok with that implication of fragility and you prefer to leave harmful, I can live with it. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, 13 Nov 2008, John C Klensin wrote: If there were a BCP on the table that would permit us to talk about DNSRBLs that conform and those that don't, rather than about subjective opinions of behaving badly, we would, IMO, be having a rather different discussion. http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN HEBRIDES: SOUTHWEST 5 TO 7, INCREASING 7 OR GALE 8, PERHAPS SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH. RAIN, FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
I'm violating my normal rate limits here, but since this is the second time today someone twitted me for this, I need to clarify. On Thu, Nov 13, 2008 at 12:53:31PM -0500, Chris Lewis wrote: 3. DNSBLs are not in themselves bad, but the implementation of them as described in the current draft (which does describe the current state of the art in DNSBLs) _is_ bad. The current behaviour and the desirable behaviour ought to be separated, and one described while the other is standardized. Behaviour of DNSBL != information transfer protocol. What I meant by behaviour above is how the protocol behaves, and not how the administrators behave or how things behave given this or that data. This is a failure in my formulation, and I regret it. As I noted (with Olafur) in our posting the other day, the problem _I_ have with DNSBLs is that they're doing fairly serious damage to the DNS protocol. That's a fact of life given the deployed software, but I don't think it's a good thing. I refuse to state an opinion on how DNSBLs ought to be operated so that users' expectations of behaviour of the service are met. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Andrew Sullivan schrieb: As I noted (with Olafur) in our posting the other day, the problem _I_ have with DNSBLs is that they're doing fairly serious damage to the DNS protocol. That's a fact of life given the deployed software, but I don't think it's a good thing. Can you please explain what this fairly serious damage to the DNS protocol is? -- Matthias ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] How to describe the processing power
If there is an API for setting the amount of resources in RELOAD implementations, would this be done per usage or overall for RELOAD. That would affect what and how we report stuff in the diagnostics. I think the comon CPU stats are still useful along with which we could report some number set up by the user that specifies the resources. Different topology plugin apps could then use different heuristics to perform neighbor selection based on this information depending on what they are aimed at. I agree that what is proposed here should both help debug an overlay as well as help in populating some metrics data which can then be used by topology plugins. On a related note, would metrics collected using a Chord topology plugin be useful to a Pastry topology plugin. Due to the use of nodeids it may be hard to reuse this information across topology plugins. Thanks, Saumitra From: Roni Even [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2008 6:35 AM To: 'Song Haibin'; Das, Saumitra; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: RE: [P2PSIP] How to describe the processing power Song Haibin, Your response It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. does also address Bruce question. My view is that the pure CPU power or CPU current usage are good but the question is if they are relevant for the decision since the user may limit the amount of resources it wants to allocate for the p2p application. This may be based on percentage from the link or number of connections. Roni Even From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Song Haibin Sent: Thursday, November 13, 2008 5:07 AM To: 'Das, Saumitra'; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Das, See inline. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:12 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Song, Processing power would be more informational in terms of CPU load. A good example of what would be useful would be to look at the comon monitoring tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It uses the following metrics for selecting nodes based on CPU and I have found such selection to be very useful in determining the performance of a slice on the machine. [Song] It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. From the comon site, these are some metrics that may be useful CPU Speed Busy CPU Sys CPU Free CPU These fields give some insight into the CPU behavior of the node. The CPU Speed is just the speed of the processor in gigahertz. The Busy CPU field gives the % of time the CPU is utilized, and the Sys CPU field specifies what percentage of time the CPU is spending in the OS. Both of these values are the maximum values over the past 5 minutes. The Free CPU indicates how much of the CPU a spin-loop was able to obtain, giving some insight into how much of the node's CPU a new slice would receive. We could define these fields and leave it optional as to whether all of them are required. i.e. running a spin-loop may be expensive for some devices. [Song] This is helpful. I'm very glad to see this monitoring tool in the planetlab testbed. If it works well in the planet lab, we may have it included in the diagnostics draft after discussion. I also see other useful metrics for other parameters in the page (http://summer.cs.princeton.edu/status/). Best, Saumitra www.saumitra.info Date: Tue, 11 Nov 2008 15:12:21 +0800 From: Song Haibin [EMAIL PROTECTED] Subject: [P2PSIP] How to describe the processing power To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Dear all, In p2psip diagnostics draft http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt , we have some doubt about how to describe one of the diagnostic information: processing power. We propose to use the unit of MIPS to describe it. However, the Max number of connections may be another choice. Do you have any good suggestions? Best Regards, Song Haibin Email: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, Nov 13, 2008 at 1:25 PM, Matthias Leisi [EMAIL PROTECTED] wrote: Andrew Sullivan schrieb: As I noted (with Olafur) in our posting the other day, the problem _I_ have with DNSBLs is that they're doing fairly serious damage to the DNS protocol. That's a fact of life given the deployed software, but I don't think it's a good thing. Can you please explain what this fairly serious damage to the DNS protocol is? I would also like to better understand this concern. Regards, Al -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, Nov 13, 2008 at 07:25:32PM +0100, Matthias Leisi wrote: Can you please explain what this fairly serious damage to the DNS protocol is? The message I posted from Olafur and me the other day is supposed to explain this already: http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html For the impatient, one fundamental problem is that the current behaviour uses A records that do not contain host addresses, which is contrary to the definition of an A record. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
--On Thursday, 13 November, 2008 12:53 -0500 Chris Lewis [EMAIL PROTECTED] wrote: 2. DNSBLs are in themselves bad, because there is no way to guarantee that they won't contain false positives; they are nevertheless possibly useful, but the trade-offs are inadequeately described in the current document. If all that's missing is a few sentences in the Security Considerations section, I'm sure that we can get somewhere with that, on the other hand, discussion of those types of tradeoffs probably don't belong in this draft, but a BCP. But there is no BCP. There is a draft that has been cited a few times, but no request for the IETF to review and publish it. It has never been the practice for the IETF to approve a standards-track document that is known to be too weak without some material with the promise that material will appear at some point in the future and will be adequate. Chris, I can't promise success, but let me at least suggest how to have a very different, and potentially more constructive, discussion. (1) This document gets withdrawn, or at least suspended, in its current form. (2) You and your colleagues ask for a WG. If there is as much consensus and work done already as we have been told, it could have a very aggressive schedule. However, the draft charter should reflect the set of documents you think are needed, how they connect to each other, and what topics they cover. It should also permit a clear discussion about the community's expectations and conditions for approach of DNSBL documents, independent of trying to pick apart (or advance) one particular document. (3) If you can get that charter approved, you submit documents that are closely related either together or in some sequence consistent with the charter and/or their relationships. If you cannot get the charter approved, then I think this is hopeless unless you decide to simply publish a series of Informational documents with clear statements about what they represent. Just my opinion of course, but it appears to me that the present discussions are going nowhere that is likely to lead to standardization of the current document in its present form. The observation that both those who favor standards-track publication of the document and those who dislike it (or RBLs generally) for one reason or another are kicking the same dead horse (Lisa has already posting a note indicating that she doesn't see sufficient consensus to support the document for standardization in its current form, which makes it dead unless another IESG member comes forward to sponsor it) moves neither the document nor the discussion forward. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] P2PSIP diagnostics: PING discussion
Hi Roni, What I mean is that typical machines on the planetlab testbed (linux based) show this drift. This may be alleviated with xp boxes since they may sync silently with time.windows.com when a network connection is up. In linux, clock drift problems have been known to exist because ntpdate may not be setup to work often enough. Thanks Saumitra From: Roni Even [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2008 6:24 AM To: Das, Saumitra; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: RE: [P2PSIP] P2PSIP diagnostics: PING discussion Hi, I am not sure what you mean NTP refresh, if the test was using the system clock than you would expect in XP that it will be updated every tick which is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC 3550) for synchronization and the RTP time is using the system clock which may add skew but it is not because of NTP. Roni Even From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 11:31 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion Hi Song, Even in the planetlab testbed, the following paper at PAM 2008 ( http://pam2008.cs.wpi.edu/slides/pathak.ppt ) shows that more than 40% of nodes have more than 20ms NTP error. In a general overlay we are likely to find a larger fraction of nodes with error in their NTP time (since the planetlab testbed is managed by the people who own the machines while general overlay nodes are unlikely to be that well maintained). Unless NTP refresh is made mandatory within a p2psip implementation, relying on ntp would be unlikely to be helpful to diagnostics Thanks Saumitra www.saumitra.info === Dear all, In P2PSIP base protocol, Ping is used to test connectivity along a path. However, connectivity quality can not be measured well without some useful information, such as the timestamp and HopCounter. In p2psip diagnostics draft version 03 http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt we extend the Ping message payloads with a few kinds of useful information for connectivity quality check purposes. The initiator node receiving the Ping response should compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops. About the Timestamp, we are not sure if the NTP time is a good candidate for it, or we have other ways to describe it, or we don't need the timestamp at all. But if NTP time is used in the overlay, then it is a good choice, because every peer along the message path will know when the message is generated, and it is easy for the peer along the path to calculate the message latency. However many overlays may not be synchronized with the NTP time. Any comments? Best Regards, Song Haibin Email: melodysong at huawei.com Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
At 10:39 AM -0800 11/13/08, Andrew Sullivan wrote: On Thu, Nov 13, 2008 at 07:25:32PM +0100, Matthias Leisi wrote: Can you please explain what this fairly serious damage to the DNS protocol is? The message I posted from Olafur and me the other day is supposed to explain this already: http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html For the impatient, one fundamental problem is that the current behaviour uses A records that do not contain host addresses, which is contrary to the definition of an A record. A Andrew, Thanks for the pointer. I had missed this technical comment in the crowd, and I think it is very important indeed. By re-using RRs with context-specific semantics, the proposal does serious harm to interoperability. Andrew and Olafur suggest one way around this (give a new RR for this use); there are others, but this one is both available and makes sense for this usage. They note that it would take some time to get this deployed. I believe that the rate of update among DNS-based reputation services is somewhat higher than Andrew and Olafur seem to, but the change should go forward *whether this draft is standardized or not*. It's important for the interoperable understanding of the DNS namespace for this to occur (or one of the related methods, like using a class other than IN to occur). regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [P2PSIP] How to describe the processing power
Hi Song, I agree that this could be used for various things like 1. Overall overlay status information for the overlay deployer 2. Peer selection for neighbor table entries by topology plugins 3. And maybe also designating functionalities to nodes based on metrics observed Yes, there are other metrics from comon related to memory usage, bandwidth use which may also be useful. Thanks Saumitra From: Song Haibin [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 12, 2008 7:07 PM To: Das, Saumitra; [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: RE: [P2PSIP] How to describe the processing power Dear Das, See inline. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:12 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] How to describe the processing power Dear Song, Processing power would be more informational in terms of CPU load. A good example of what would be useful would be to look at the comon monitoring tool (http://summer.cs.princeton.edu/status/) for the planetlab testbed. It uses the following metrics for selecting nodes based on CPU and I have found such selection to be very useful in determining the performance of a slice on the machine. [Song] It is also useful in selecting peer for a neighbor table entry, when there are multiple choices existing and for the overlay management to collect the overall status of the overlay. From the comon site, these are some metrics that may be useful CPU Speed Busy CPU Sys CPU Free CPU These fields give some insight into the CPU behavior of the node. The CPU Speed is just the speed of the processor in gigahertz. The Busy CPU field gives the % of time the CPU is utilized, and the Sys CPU field specifies what percentage of time the CPU is spending in the OS. Both of these values are the maximum values over the past 5 minutes. The Free CPU indicates how much of the CPU a spin-loop was able to obtain, giving some insight into how much of the node's CPU a new slice would receive. We could define these fields and leave it optional as to whether all of them are required. i.e. running a spin-loop may be expensive for some devices. [Song] This is helpful. I'm very glad to see this monitoring tool in the planetlab testbed. If it works well in the planet lab, we may have it included in the diagnostics draft after discussion. I also see other useful metrics for other parameters in the page (http://summer.cs.princeton.edu/status/). Best, Saumitra www.saumitra.info Date: Tue, 11 Nov 2008 15:12:21 +0800 From: Song Haibin [EMAIL PROTECTED] Subject: [P2PSIP] How to describe the processing power To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Dear all, In p2psip diagnostics draft http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt , we have some doubt about how to describe one of the diagnostic information: processing power. We propose to use the unit of MIPS to describe it. However, the Max number of connections may be another choice. Do you have any good suggestions? Best Regards, Song Haibin Email: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Skype: alexsonghw ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Andrew Sullivan schrieb: http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html For the impatient, one fundamental problem is that the current behaviour uses A records that do not contain host addresses, which is contrary to the definition of an A record. And this counts as fairly serious damage to the DNS protocol? This seems like a *tiny* bit exaggerated. The suggestion to use a dedicated RRTYPE is nice, but many others have failed in this endeavour before. -- Matthias ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
At 11:04 AM -0800 11/13/08, Matthias Leisi wrote: The suggestion to use a dedicated RRTYPE is nice, but many others have failed in this endeavour before. -- Matthias What do you mean failed in this endeavour? failed to get an RR assigned, or failed in deployment? regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, 13 Nov 2008, Ted Hardie wrote: Thanks for the pointer. I had missed this technical comment in the crowd, and I think it is very important indeed. By re-using RRs with context-specific semantics, the proposal does serious harm to interoperability. Is there any evidence for that? Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHERLY OR SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN NORTH UTSIRE AT FIRST, AND PERHAPS GALE 8 IN VIKING LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [P2PSIP] P2PSIP diagnostics: PING discussion
On 13 Nov 2008, at 09:24, Roni Even wrote: I am not sure what you mean NTP refresh, if the test was using the system clock than you would expect in XP that it will be updated every tick which is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC 3550) for synchronization and the RTP time is using the system clock which may add skew but it is not because of NTP. One minor clarification: RTP uses an NTP format timestamp, but it doesn't require the use of NTP. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Context specific semantics was Re: uncooperative DNSBLs, was several messages
At 11:23 AM -0800 11/13/08, Tony Finch wrote: On Thu, 13 Nov 2008, Ted Hardie wrote: Thanks for the pointer. I had missed this technical comment in the crowd, and I think it is very important indeed. By re-using RRs with context-specific semantics, the proposal does serious harm to interoperability. Is there any evidence for that? Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHERLY OR SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN NORTH UTSIRE AT FIRST, AND PERHAPS GALE 8 IN VIKING LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. The draft currently says: DNSxLs also MAY contain an A record at the apex of the DNSxL zone that points to a web server, so that anyone wishing to learn about the bad.example.net DNSBL can check http://bad.example.net. That's an example in which an A record in this zone has the standard DNS meaning and the expectation is that you can use it construct a URI. The other A records have a specific meaning in which the data returned indicates that indicates something about its reputation in a specific context (what reputation etc. being context specific). One of these things is not like the other. Using the same record type for both creates a need to generate some other context that enables you to figure out what was really meant. The whole approach here is An A record in this zone has a meaning different from the meaning in other zones. That creates a DNS context for the RRTYPE based on the zone of the query, which is not what the DNS currently uses for disambiguating the types of requests/responses. Using a different RR type puts you back into the standard way of doing things. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Clarifying harm to DNS (was: uncooperative DNSBLs, was several messages_
On Thu, Nov 13, 2008 at 08:04:11PM +0100, Matthias Leisi wrote: And this counts as fairly serious damage to the DNS protocol? This seems like a *tiny* bit exaggerated. The DNS is a distributed, loosely-coherent database of typed data. If we start throwing away the types, it seems like pretty serious damage to me. When my DNS client gets back an A record from what appears to be a DNS server answering DNS queries according to the standard DNS protocol, it ought to be able to rely on the the A record containing a host address, because that's what an A record is defined as containing (by RFC 1035). But the DNSxL document describes using A records such that that the RDATA contains something that looks like a host address, _but that isn't_. There's no way to tell that such is the case except by knowing the context of the query and the contents of the response. What this does is make the answer different _in kind_ depending on its content. Note that this isn't like the (otherwise lamentable) example of TXT records being used as protocol elements -- they at least were always defined as being nothing more strongly typed than text strings. If the protocol as described in the -dnsbl- draft does not do violence to the DNS protocol, then I guess I don't know what would. I thought this argument was plain in the original note Olafur and I sent, but I gather technical comments of this nature might have been lost in the fog (well, flames, in this case) of war. I hope the above clarifies. I should observe that I'm not so naive as to suppose the existing use is going to disappear any time soon. That's a poor reason, in my opinion, for turning a bad use into a standard of any kind, when we can instead document the existing (bad) use for everyone's information, and suggest an alternative that accomplishes the same goal without causing the same harm. If that's not the point of an interoperability-focussed network standards organization, I guess I also don't know what we're doing here. A -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IP-based reputation services vs. DNSBL (long)
Hallam-Baker, Phillip wrote: To answer your question about how they got round port 25 blocking, my guess is that they sent the initial packet out on yet another connection that was unblocked. Actually, I answered that question - they didn't get around port 25 blocking. They never sent from the (say AOL dialup) side, only from the high speed side. three way handshaking emulation of what's supposed to be two way, but physically only two (not three) machines. Since they're on the same machine, the timing is not much of an issue. Got high speed spam emission, at the expense of burning (lots of) free AOL low speed access dialup disks. Especially if you pipelined (whether the recipient said it was okay or not) multiple parallel SMTP streams. [The recipient usually has no way of knowing whether you're really waiting for it's SMTP command return codes or not. Which is exemplified by one particular type of HTTP proxy attack. Arrange the entire sending side's SMTP commands in one buffer (eg: a HTTP CONNECT proxy), and send it all at once. Works just fine if you don't care about errors. Which high volume spammers don't.] I have seen something similar described recently in the context of a cyber-conflict type attack. Potentially still useful technique, where the economies are different. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Can we have on NAT66 discussion?
Well yes, that is precisely the reason I beleive that we need to take a look at a higher level and decide on one single answer to questions such as: * What describes the boundary between the network and the inter-network? * How does a client endpoint connect to a service endpoint? * How does a sevice endpoint advertise its existence at the network border? I know that I can give clear and concise answers to these questions, but I think many who argue against the concept of NAT prefer not to think about them. The single answer to the service endpoint discovery problem in my view is that it is a DNS infrastructure problem and no other infrastructure should be involved, certainly not IP. By infrastructure here I am taking account of the fact that we might in theory replace the DNS protocol, but only if the result was transparent at a logical level. Many of the problems with NAT result from the fact that we have protocols such as FTP that use the IP address and port to pass a pointer to a service endpoint - yuk! Another set of problems come from the fact that by default a NAT box will block incomming connections. This is in many cases exactly the intended outcome, but not always. It would be really nice if there was actually a practical, interoperable video conferencing system that works peer-to-peer through NAT at both ends. From: Scott Brim [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 11:51 AM To: Hallam-Baker, Phillip Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. That's not the problem. The issue is location. Once we have established a session then how the packets are labeled for network layer purposes doesn't matter much (modulo security) but how do we get communications set up in the first place? Suppose I want to reach foo. Who do I ask to find a locator for him? Split DNS works fine when there are just two states, inside and outside -- a DNS server can be configured to know how to respond in each case. But if you were to sprinkle NATs all over the Internet there would be no place that could give a confident answer about how I, over here, should name foo in the network layer in order to get a packet to him, and have that answer get to me in the correct form. So it is very important to understand where we think it might be safe to put what kinds of NATs. swb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Can we have on NAT66 discussion?
You are far too dogmatic in your assertion of what is a security control here. I do not think that there are many folk in the security area who would make such a direct contradiction. There might be dispute as to whether NAT is an effective security control, Steve Bellovin has written papers on that (which I consider less than conclusive) but NAT is certainly employed as a security control and is certainly effective against certain types of real world attack. NAT is used to provide two types of security: 1) A lighweight, verifiable means of blocking inbound connections 2) A lightweight means of limiting the ability of external observers to map the internal structure of a network. The first is interesting as the property that is provided by NAT that is not provided by a standard firewall is auditability and provability. A NAT design is failsafe, it is highly unlikely that a mistake in the NAT code will cause inboud connections to work.it takes effort to make it work. A firewall with no NAT component is not failsafe, if there are bugs packets can get through. There is no way for an independent auditor to determine if a black box is a firewall or a standard ethernet hub unless it is seen in the act of rejecting a packet. The second is something that some folk dispute, but nevertheless is a real obstacle to certain types of (legitimate) investigation. The amount of effort and network access required to circumvent a NAT scheme is considerable and does not lend itself to simple automation. So what we have here is the ongoing dispute between the adherents of old style 'security perfectionists' who think that any security flaw renders a system ineffective and the folk like myself who have long argued that security is risk management (yes, even before that book came out). From: Eric Klein [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 2:07 PM To: Hallam-Baker, Phillip Cc: Mark Townsley; Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? Hi Phillip, On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on. If you want to effect a transition from IPv4 to IPv6, the only way to do that effectively is to design a protocol stack in which the applications simply do not care whether their packets are routed over IPv4, IPv6 or carrier pidgeon. Agreed NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts. NAT is not and never was a security feature, it was a way to use fewer numbers because they were hard to get. Please stop the falacy that NAT in any way is related to security, otherwise we would not need firewalls. I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed. On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it. This is not quite true, the ones who have been argueing against it have constantly asked why we need it. But we still do not know why we need NAT, no one has done the gap analysis. And yes, I have been guilty of many of the same mistakes. But unlike some folk I am not about to compound that mistake by telling the folk who want NAT66 that they should visit a re-education camp and unlearn their heretical thoughts. The only reason NAT is bad in practice is because some people were so opposed to the concept that they decided it would be a good thing to allow designs that
Re: uncooperative DNSBLs, IETF misinformation (was: several messages)
On 13 Nov 2008, at 19:39, Andrew Sullivan wrote: On Thu, Nov 13, 2008 at 07:25:32PM +0100, Matthias Leisi wrote: Can you please explain what this fairly serious damage to the DNS protocol is? The message I posted from Olafur and me the other day is supposed to explain this already: http://www.ietf.org/mail-archive/web/ietf/current/msg53776.html For the impatient, one fundamental problem is that the current behaviour uses A records that do not contain host addresses, which is contrary to the definition of an A record. Is this not a truly desperate grasping at straws? So far I have heard here: - DNSBLs are not much used so they should not be recognized. (we alone have 1.4 billion end-users and our DNSBLs are used by 2/3 of internet networks, including all giant freemail providers) - DNSBLs are temporary fad, they'll never last. (we've been serving DNSBLs for 10 years) - DNSBLs are bad for email. (we alone flag some 80 billion spam emails *per day*, spam which would otherwise clog servers and render email completely useless) - DNSBLs stop very little spam. (our DNSBLs catch 80-90% of spam out-front, and 99% if used as we recommend in: http://www.spamhaus.org/effective_filtering.html ) - DNSBLs have huge False Positives. (at 80 billion spams stopped per day, if we had even a miniscule FP level there would be a worldwide outcry and everyone would stop using us. Do the maths. Our FP level is many times lower than any other spam filter method by a very, very long way) - DNSBLs break email deliverability. (DNSBL technology in fact ensures that the email sender is notified if an email is rejected, unlike Bayesian filters/content filters which place spam in the user's trash without notifying the senders) - DNSBLs sit in the middle of an end-to-end email transaction (see: http://www.spamhaus.org/dnsbl_function.html for enlightenment) - IETF should not recognize DNSBLs because it may upset IETF sponsors. (the IETF sponsors and founders list reads as a who's who of DNSBL users, we ourselves have contracts with at least 60% of the IETF sponsor corporations for the use of our DNSBLs. Upset them my foot.) - Someone from BT said DNSBLs should not be standardised (BT has a contract with Spamhaus to use our DNSBLs on its network, we're not sure why BT would prefer the DNSBLs it uses to not be standardised but we'll ask them at contract renewal time ;) - DNSBLs are all bad because someone had a bad experience with SORBS. (well, we're not SORBS. Nor are Trend Micro, Ironport, or the other responsible DNSBL operators) and - DNSBLs cause fairly serious damage to the DNS protocol because they use A records that do not contain host addresses. (127.0.0.0 is reserved for IANA Special Use. It is non-net-routable. DNSBLs using 127.0.0.2 cause absolutely no 'damage' whatsoever) Please could the arguments against standardisation use some better and correct facts, as most of the arguments being presented against standardisation started off poor and are deteriorating into farcical. Steve Linford Chief Executive The Spamhaus Project http://www.spamhaus.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote: Well yes, that is precisely the reason I beleive that we need to take a look at a higher level and decide on one single answer A single answer? That doesn't seem compatible with what the internet has evolved into over the past decades. to questions such as: * What describes the boundary between the network and the inter- network? * How does a client endpoint connect to a service endpoint? * How does a sevice endpoint advertise its existence at the network border? Sounds an awful lot like the telco networks of yore. One of the cool things about the internet architecture is that many aspects of it are recursive. Having these borders is incompatible with that. On the other hand, many service providers use nasty hacks to get their stuff to work (just think about a concept like putting authentication in DHCP!) because the IP architecture doesn't allow for a service provider / customer demarcation point. By infrastructure here I am taking account of the fact that we might in theory replace the DNS protocol, but only if the result was transparent at a logical level. And how would the new DNS be better than the old one, apart from such obvious things as removing the easy spoofing? The reason that people Many of the problems with NAT result from the fact that we have protocols such as FTP that use the IP address and port to pass a pointer to a service endpoint - yuk! is that you can't realistically do a referral based on a DNS name: - DNS isn't always available - DNS is insecure - caching and TTLs and incorrect implementation of same make that an inconsistent view of the same data in different places can persist for significant amounts of time - performance is relatively poor - some users don't have a DNS name - a large number of users can't set their own DNS name - dynamic IP addresses usually come with static DNS names, i.e., with the address change the name changes as well And then there is of course the issue of revisiting a very large number of protocols and implementations of these protocols in order to support FQDN based referrals. But apart from these issues I agree with you. It would be really nice if there was actually a practical, interoperable video conferencing system that works peer-to-peer through NAT at both ends. Not sure how this applies to the NAT66 discussion. The choice that we're talking about is between a type of NAT that can fairly easily support this versus no NAT, so it also works. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IP-based reputation services vs. DNSBL (long)
Yes, there are many spammers who use systems that essentially send out the buffer in a single packet. Even if not doing one arm routing they use it for acceleration. Which is why a somewhat effective spam pre-filter is to simply enforce proper SMTP protocol use and reject a connection if the other side has queued up RCPT and DATA commands in the HELO packet. From: [EMAIL PROTECTED] on behalf of Chris Lewis Sent: Thu 11/13/2008 3:52 PM Cc: IETF Subject: Re: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip wrote: To answer your question about how they got round port 25 blocking, my guess is that they sent the initial packet out on yet another connection that was unblocked. Actually, I answered that question - they didn't get around port 25 blocking. They never sent from the (say AOL dialup) side, only from the high speed side. three way handshaking emulation of what's supposed to be two way, but physically only two (not three) machines. Since they're on the same machine, the timing is not much of an issue. Got high speed spam emission, at the expense of burning (lots of) free AOL low speed access dialup disks. Especially if you pipelined (whether the recipient said it was okay or not) multiple parallel SMTP streams. [The recipient usually has no way of knowing whether you're really waiting for it's SMTP command return codes or not. Which is exemplified by one particular type of HTTP proxy attack. Arrange the entire sending side's SMTP commands in one buffer (eg: a HTTP CONNECT proxy), and send it all at once. Works just fine if you don't care about errors. Which high volume spammers don't.] I have seen something similar described recently in the context of a cyber-conflict type attack. Potentially still useful technique, where the economies are different. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSV Area review of draft-ietf-dime-qos-parameters
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. This ID describes some useful technology but I think it can be improved. My main issue is that the ID does not do a good enough job of making clear what the units of the parameters are or even what the meaning of some of the parameters are. Some of the information can be found by looking at the RFCs that are referenced but it would be cleaner to just include the information in this document. I was initially confused by the fact that section 3 contained no information on what the units of the parameters are but much of this is covered in section 4. (if it were up to me I'd put the units in section 3 as well - e.g. in section 3.2 I'd say that The Path Latency parameter (expressed in usec) refers to the accumulated latency ⦠) But not all of the units are explained in section 4 and some terms are left undefined. I'll only provide some examples here - I suggest that the authors step through the document and be sure that the units as well as the terms are defined in every case. For example, in section 3.1. The value large is not defined or explained, nor is the term policed unit. The document does not say what the units for rate (bytes per second?, packets per usec?) are or the units for bucket size (bytes?) - an educated guess can be made but it would be better if no guessing were needed. Another example, in section 3.2. The units for packet loss rate are not given (packets per second? % of packets?) Also, in section 4.5. It would be nice to have a few words say what 99.9%-ile means and how to calculate it for those who might not know nit: section 4.8 says A description of the semantic of the parameter values can be found in [RFC2212], [RFC2215]. Should this say [RFC2212] and [RFC2215]? nit: the first sentence under section 4.13.3 is not a sentence nit: section 6.1 - 4th pp says 1 to 511: Standards Action the pp following says range of 0-511 - should these be consistent? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Context specific semantics was Re: uncooperative DNSBLs, wasseveral messages
Since I have been critical of the insistence on a new RR in other contexts, I will give the reasons why I am unconvinced in this particular case and indeed would argue that a specific RR would be more effective. First, let us consider the reasons why you might want to re-use an RR rather than define a new one: 1) Avoid running out of RRs. 2) Incompatibility with existing DNS infrastructure 2a) DNS publishing server 2b) DNS caching/lookup server 2c) DNS client (Yes, I find the standard nomenclaure confusing and ambiguous) I do not see that the first objection applies in this case. This is a very specific application, it is providing a description of a part of the Internet address space which is a primary function of the DNS. Where I do see creation of new RRs to be a concern is in cases where there is a combinatorial issue, for example a scheme that would require a new RR to be created for each Internet application protocol. That gets us into the same problem as port exhaustion and is unacceptable. The second issue is somewhat different to the analysis for DKIM or other enterprise deployments. A DNSBL is almost always deployed by a specialist on dedicated infrastructure. I do not see any reason to object to a scheme that would require such a specialist to upgrade their DNS publishing server. The same is also true at the client end. Email infrastructure that uses a DNSBL should not be using the local DNS resolver to cache data. If the data is worth caching cache it in the email server. If you have enough email servers to make another arrangement worthwhile you have enough to know exactly what you are doing. Against this there is the fact that the original Vixie DNSBL spec is terrible. Reuse of the A record makes the somewhat bizarre assumption that all the info that you might want to put into a blacklist can be encoded into a 32 bit binary field. At least use a TXT record if you are going to go that route. Take the opportunity to get a little more descriptive info in there. For example, is the basis for the info objective or subjective when was the information last updated? One problem with DNSBLs is that some folk start a service because they think it might be fun and then get bored with maintenance but the server stays up in perpetuity. Its like one of those abandonded lobster pots that just acts as a permanent death trap for sea creatures. I know that there are less people starting email blacklists today, but just wait till the next set of blacklists are required. We will have the same process of boom - bust and gradual decay. Having some better info on what the age of the complaint is would be a big improvement. At least that way the DNSBLs that are designed in good faith will automatically disable themselves over time. From: [EMAIL PROTECTED] on behalf of Ted Hardie Sent: Thu 11/13/2008 3:08 PM To: Tony Finch Cc: ietf@ietf.org Subject: Context specific semantics was Re: uncooperative DNSBLs, wasseveral messages At 11:23 AM -0800 11/13/08, Tony Finch wrote: On Thu, 13 Nov 2008, Ted Hardie wrote: Thanks for the pointer. I had missed this technical comment in the crowd, and I think it is very important indeed. By re-using RRs with context-specific semantics, the proposal does serious harm to interoperability. Is there any evidence for that? Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHERLY OR SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN NORTH UTSIRE AT FIRST, AND PERHAPS GALE 8 IN VIKING LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. The draft currently says: DNSxLs also MAY contain an A record at the apex of the DNSxL zone that points to a web server, so that anyone wishing to learn about the bad.example.net DNSBL can check http://bad.example.net http://bad.example.net/ . That's an example in which an A record in this zone has the standard DNS meaning and the expectation is that you can use it construct a URI. The other A records have a specific meaning in which the data returned indicates that indicates something about its reputation in a specific context (what reputation etc. being context specific). One of these things is not like the other. Using the same record type for both creates a need to generate some other context that enables you to figure out what was really meant. The whole approach here is An A record in this zone has a meaning different from the meaning in other zones. That creates a DNS context for the RRTYPE based on the zone of the query, which is not what the DNS currently uses for disambiguating the types of requests/responses. Using a different RR type puts you back into the standard way of doing things. regards, Ted Hardie ___ Ietf mailing list
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
In message [EMAIL PROTECTED], Tony F inch writes: You also need the server to provide a verifiable TLS certificate. The vast majority of them are not. This problem is perhaps even harder to fix than the lack of DNSSEC. Just use DNSSEC and CERT records to do that. If self signed, look in the DNS for the CERT. Accept if signed and validated by DNSSEC. Have a low TTL on the CERT so as to not blow the DNS cache (caches can enforce this if needed) and maintain a on disk cache of the certs retrieved via the DNS as they have their own validitiy period. Attempt to retieve a new one via DNS of the on disk one doesn't match. Certs that are signed by private CAs are harder to deal with as you don't have the linkage from the name to the CA. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-cheshire-dnsext-dns-sd-05
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-cheshire-dnsext-dns-sd-05 Reviewer: Ben Campbell Review Date: 2008-11-13 IETF LC End Date: 2008-12-02 IESG Telechat date: (if known) Summary: This draft is on the right track, but there are open issues that should be considered prior to publication. General Comments: -- Intended Status I am not sure I understand the intent of this draft. It has an intended status of informational, but it defines protocol of a sort, or at least conventions that would benefit from standardization. I don't think that is necessarily a problem per se, if the intent is something along the lines of here's a protocol used by certain deployed products, and if you want to interoperate with them you can follow this If that is the case, it would help to be explicit about it in the first few paragraphs of the intro, and perhaps even the abstract. Or maybe a Scope of Applicability section. I further note that there are multiple last call comments that suggest this should be a proposed standard, and that there are proposed standard efforts that would like to use it. [I fully admit to not knowing the history that led to this work being informational, so there may be very good reasons I don't know about.] -- Relationship to existing work On a shallow review, certain aspects of this draft seem to compete with some of the DDDS/NAPTR work, for example, RFC 4848 and 3958. I am curious what how this draft relates to that, and what benefits the author's believe DNS-SD has over, say, U-NAPTR. (This comment is somewhat dependent on the above comment about intended status--if this is truly informational, then it's probably not a problem if it competes with existing work. But if it became a proposed standard, it would be useful for it to contrast itself to RFC 4848 and/or RFC 3958) -- User Interface recommendations: While there is good information here, I wonder why it belongs in this draft, rather than in a separate paper. While most of the draft describes how to implement DNS-SD, The user interface considerations sections really serve to evangelize subjective viewpoints (most of which I agree with, btw) on UI design. UI design is not something the IETF tends to take on in general. Again, this interacts a bit with my informational vs proposed standard comments above. While most of the draft could conceivably appropriate for a standards track RFC, the UI considerations section is truly informational or possibly BCP material. Also, I assume the UI guidance would apply to other service discovery mechanisms as well. If so, that further supports separating it out. -- Tone Several parts of this draft have a strong marketing tone. An RFC should take more of an objective engineering tone. I will point out some specific (but non-exhaustive) examples in the detailed comments below. Specific Comments: --Section 3, 4th paragraph: ... so simple to implement... This is a very vague test. How do you define simple to implement? I personally know of implementors and operators that struggle getting basic DNS right. -- 5th paragraph: Does this draft purport to meet the requirements in [ATalk]? -- Section 4.2, example 3 paragraphs from end: TheXXX Floor.apple.com examples should use example.com -- 2nd from end: ... this document recommends... Since you are using 2119 normative language elsewhere, I suspect this should have been a normative statement. (that is, s/recommends/ RECOMMENDS) -- Last paragraph: ... MAY choose to retry the query using Punycode Did you really intend that to be a MAY? This seems to imply that it is possible to have records that you cannot successful query without using Punycode--which would seem to support making this at least a SHOULD. -- Section 4.5.3, 2nd paragraph: nit - it might be better to avoid the term machine and instead use name server or maybe even zone, since these do not necessarily map to a single piece of hardware. -- Section 5, last paragraph: This effectively says that SRV clients SHOULD do SRV correctly. That seems a little weak--but since this paragraph really only restates requirements from the SRV RFC, you can probably drop in entirely, or if you want it for background purposes, restate it descriptively rather than normatively. -- Section 6.7, paragraph 1 Is this recommendation intended to be normative? Also, in the last sentence, do you want to encourage clients to ignore _lower_ version numbers? Doesn't that hurt backward compatibility? -- Section 8 This entire section seems to assume that devices are creating their own SRV records. You mention elsewhere that this is not a requirement,
Re: uncooperative DNSBLs, was several messages
Windows is one of the most prominent users of DNS. I remember you could send them netbios packets and windows would put them into the DNS cache. Be asured they will put dnsbl into the cache and then the famous IE will look for cnn.com on 127.0.0.1 It makes sense after all because the spammers do host malware sites too. Looking up a dnsbl will prevent your browser from accidently showing malware sites :) Be asured sooner or later some silly bugger will try and it works - no more malware and no popups either. Kind regards Peter Tony Finch wrote: On Thu, 13 Nov 2008, Ted Hardie wrote: Thanks for the pointer. I had missed this technical comment in the crowd, and I think it is very important indeed. By re-using RRs with context-specific semantics, the proposal does serious harm to interoperability. Is there any evidence for that? Tony. -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
Hallam-Baker, Phillip wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. On the contrary, the idea that an application must not care that the IP address of a packet is consistent from source to destination is plain bonkers. Even assuming the existence of a higher level identifier and a secure, fast, scalable, reliable way of finding routes to that identifier, there will still be some need to talk to a host or an interface. And nobody has demonstrated an application-independent mapping service that is anywhere nearly up to that task. Until somebody does, statements about what the architecture should do, or what applications should not do with addresses, are at best wishful thinking, and at worst delusion. And the more often someone makes such a statement without qualification, the more it looks like the latter. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Can we have on NAT66 discussion?
Well that is precisely what distinguishes an 'architecture' from a collection of ad hoc heuristic approaches. It is not necessarily going to be the case that every Internet protocol is going to precisely map to the Internet architecture. In fact I would suggest that people are never going to fix FTP. But what you can do with an architecture is to tell application designers, 'here is the Internet, here is how you plug your stuff into our stuff and this is what you can expect to happen when you do it that way and you can expect it to continue to work that way for the indefinite future'. Sure there are going to be legacy exceptions, but there is a big difference between having a system with six legacy protocols that are not quite compliant and one where new incompatibilities are being established every day. From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 4:34 PM To: Hallam-Baker, Phillip Cc: [EMAIL PROTECTED]; Behave WG; IETF Discussion; Routing Research Group Mailing List Subject: Re: [BEHAVE] Can we have on NAT66 discussion? On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote: Well yes, that is precisely the reason I beleive that we need to take a look at a higher level and decide on one single answer A single answer? That doesn't seem compatible with what the internet has evolved into over the past decades. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
On Thu, 13 Nov 2008, David Romerstein wrote: I believe that it's listed 'correctly', per that FAQ, for one reason: CNAME, not PTR. SORBS *appears* to want PTRs (with appropriate TTLs). Following up to myself (bad form!), I'm mistaken. This IP was probably originally listed because it's in a huge swath of hostnames with generic rDNS. I submitted a ticket to have it delisted, was rejected by the robot, and found (in discussion w/the SORBS admin[1]) that a DNS lookup on that IP failed: [86400] 141.17.85.65.in-addr.arpa domain name pointer newgate.xpasc.com. Host 142.17.85.65.in-addr.arpa query failed: Connection Timed Out [86400] 143.17.85.65.in-addr.arpa CNAME pointer 65.85.17.143.xpasc.com. (Interestingly, out of the whole /24, that's the only lookup that failed) There's a 48 hour timeout before a new request for this IP can be submitted. If this host appears in anyone's MX record, let me know - that can push this request to a different queue. -- D [1] SORBS' admin, who answered by despite being on a well-deserved holiday ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
e.g. the .local TLD. When microsoft introduced the .local TLD for rendezvous incompatibility, their windows boxes started to query the root-servers for nonsense like refrigerator.local When some hearty nameserver operators fighted back, loading a zone file for .local they brought campus networks down. Zeroconfig was never meant to query port 53 - but they do. As soon as some windows gurus see an official document about dnsbl they will put it into the windows dns. Looking for cnn.com on 127.0.0.1 will be fun. Some of those boxes do serve http. Kind regards Peter Ted Hardie wrote: At 11:04 AM -0800 11/13/08, Matthias Leisi wrote: The suggestion to use a dedicated RRTYPE is nice, but many others have failed in this endeavour before. -- Matthias What do you mean failed in this endeavour? failed to get an RR assigned, or failed in deployment? regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Can we have on NAT66 discussion?
It is called the principle of encapsulation. The most successful Internet protocols do not involve connections to hosts today. SMTP is a connection to a service and has been for two decades. HTTP is not quite so agile but would be had we had SRV at the time. In SMTP the IP address does not remain constant end to end and never did. Simply asserting that there will still be some need to talk to a host or an interface without giving instances is hardly a compelling argument. More proof by unsupported assertion seems to me. From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Thu 11/13/2008 5:28 PM To: Hallam-Baker, Phillip Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [BEHAVE] Can we have on NAT66 discussion? Hallam-Baker, Phillip wrote: I beleive that the question would not arise If we had a coherent Internet architecture The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. On the contrary, the idea that an application must not care that the IP address of a packet is consistent from source to destination is plain bonkers. Even assuming the existence of a higher level identifier and a secure, fast, scalable, reliable way of finding routes to that identifier, there will still be some need to talk to a host or an interface. And nobody has demonstrated an application-independent mapping service that is anywhere nearly up to that task. Until somebody does, statements about what the architecture should do, or what applications should not do with addresses, are at best wishful thinking, and at worst delusion. And the more often someone makes such a statement without qualification, the more it looks like the latter. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
Hallam-Baker, Phillip wrote: It is called the principle of encapsulation. The most successful Internet protocols do not involve connections to hosts today. SMTP is a connection to a service and has been for two decades. HTTP is not quite so agile but would be had we had SRV at the time. In SMTP the IP address does not remain constant end to end and never did. You're extrapolating a long way from a small sample size. Simply asserting that there will still be some need to talk to a host or an interface without giving instances is hardly a compelling argument. More proof by unsupported assertion seems to me. It's what you have to do to diagnose problems in deeply layered systems. You have to be able to strip away the layers that aren't working until you find one that does. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Dave CROCKER wrote: The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. I have a strong suspicion that poor design of the DNSBL protocol (and/or its interface to SMTP and NDNs) encourages more badness than is needed. For instance, what would happen if mail servers provided feedback to both senders (on a per message basis in the form of NDNs) and recipients (say, via a web page that listed messages blocked due to DNSBLs)...in both cases describing which DNSBL blocked the message and what the blocking criteria were? What if recipients could disable blocking on a per-DNSBL basis? Assuming that we're going to have reputation services, I'm looking for ways to make them more accountable/responsible. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
John: I am pleased to go with: The IESG has concluded that publication could potentially disrupt the IETF work done in WG X and recommends not publishing the document at this time. Thanks for the suggestions. Russ At 01:01 PM 11/13/2008, John C Klensin wrote: Russ, FWIW, I can live with this formulation. I would still prefer to get rid of harmful... see below. --On Thursday, 13 November, 2008 12:41 -0500 Russ Housley [EMAIL PROTECTED] wrote: To make them all parallel in structure, the first numbered item in section 3 becomes: 1. The IESG finds no conflict between this document and IETF work. ... I am happy with has concluded. The numbered list is changed as follows: The IESG review of these Independent Stream and IRTF Stream documents reach one of the following five types of conclusions. ... 3. The IESG has concluded that publication is potentially harmful to the IETF work done in WG X and recommends not publishing the document at this time. I would recommend replacing is potentially harmful with something like could impede the smooth progress of. That eliminates the issue of harm and replaces it with what is actually a slightly weaker condition. Phrases like could potentially disrupt would be roughly equivalent, again without implying that the IETF process is so fragile that the publication of a document could harm it. But, if the IESG is ok with that implication of fragility and you prefer to leave harmful, I can live with it. ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
comments on draft-ietf-p2psip-base-00 re enrollment
Hi, I propose that we should allow some flexibility in the discovery process by decoupling the enrollment server from the overlay configuration document. Currently, section 11.2 specifies that this overlay configuration file is obtained from an enrollment server. A more flexible mechanism would be for the overlay configuration file to exist on its own and instead specify an enrollment server. So I propose we add an enrollment-server address= port= required entry into the overlay configuration file. This address would then be used to contact the enrollment server and actually enroll in the overlay. The benefits of this include 1. Overlays can be advertised separately on aggregators similar to torrents. A torrent file is self contained and an overlay configuration file can be the same way. 2. With self-generated credentials specified in 11.3.1, an enrollment server may not even be part of the process and an overlay configuration file could simply be emailed to participants to create an overlay. There is no need to retrieve it from a given enrollment server. Thanks, Saumitra ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, was several messages
Keith Moore wrote: Dave CROCKER wrote: The difficulty is that the current line of argument is that because some DNSBLs are operated badly, DNSBLs are bad. I have a strong suspicion that poor design of the DNSBL protocol (and/or its interface to SMTP and NDNs) encourages more badness than is needed. Step back from DNSBLs. What you are describing is more properly a BCP for the implementation of email filters in general, and is not directly relevant to the protocols involved in any one kind of filtering. These are NOT reputation systems issues. These are filter implementation issues. The problems you ascribe below are equally (or more) applicable to almost all other filtering techniques - whether or not you're relying on external supplied filtering information. The ones that this isn't applicable (such as greylisting, or banner delays for example), are often by their very nature incompatible with your suggestions (eg: you can't quarantine a banner delay FP). As such, such considerations really belong in a entirely different document about filtering in general. Which is a fine charter for a WG, more useful than one on DNSBLs or reputation systems specifically. So, I'm going to attempt to cover your for instance from a more general perspective - showing that your for instance scenarios are already broadly implemented throughout the industry, but there are problems and caveats that you're not aware of. For instance, what would happen if mail servers provided feedback to both senders (on a per message basis in the form of NDNs) They already provide feed back to senders. Most filtering systems supply NDNs with either a reasonably direct explanation of what happened (eg: we don't allow swear words, or see http://spamhaus.org/lookup=X;), or provide means by which remediation can be achieved, eg: If you believe this is in error, please contact [EMAIL PROTECTED] with the following sessionid . [That's what ours says.] DNSBLs are perhaps the best at supplying suggested text for the NDN (eg: TXT records in the protocol spec.). Other systems aren't so consistent. But remember, it's only a suggestion. The filter implementer need not use it. We don't. On purpose. We have chosen, as a corporate, to not reveal _any_ filtering reasons in NDNs as a security measure, and get the sender to contact us for remediation (via the message I quoted above), and explanation if necessary for remediation. Any BCP that insists on the NDNs being perfectly transparent about why this email was blocked is going to be rejected by a large chunk of the industry, DNSBLs or otherwise. You want to know how to get the email blockage fixed. That's a different question than why was this was blocked. If you can satisfy the former, the latter is seldom necessary. and recipients (say, via a web page that listed messages blocked due to DNSBLs)... Many systems, particularly the large ones (eg: all outsourced spam filtering systems, all very large ISP environments etc) provide recipients with one way or another to examine filtered email, either by tagging, junk folder, web-based quarantine, or summary email notifications - we do the latter two. in both cases describing which DNSBL blocked the message and what the blocking criteria were? Many systems provide direct explanations of the reasons for why the email is in the quarantine or junk folders. Probably becomes Most if the user knows how to look. We've explicitly chosen to inhibit displaying the reason to the recipient for a particular block for three reasons - security (see above), useability (most users would have difficulty figuring out how to apply the information, so we do it for them), and finally, see below: What if recipients could disable blocking on a per-DNSBL basis? They often can. Many server-based systems implement per-user customization. However, experience seems to indicate that such functionality is almost never used, and when it is, it's almost always a all filters on or all filters off choice. Secondly, as a corporate entity (rather than a service provider), it's our email flow, and our ultimate responsibility and liability about what happens on it. In fact, legislation _requires_ us to filter certain things. Therefore, you can't opt out of our filters without a formal security exemption. A BCP requiring per-user opt-out won't be acceptable to the industry. Assuming that we're going to have reputation services, I'm looking for ways to make them more accountable/responsible. Your suggestions can't be implemented by a reputation service. Only the filter implementor can, and these suggestions apply equally to all filtering techniques. Doesn't belong in a DNSBL protocol specification. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-cheshire-dnsext-dns-sd
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The security consideration section of this document is (in its entirety): 18. Security Considerations DNSSEC [RFC 2535] should be used where the authenticity of information is important. Since DNS-SD is just a naming and usage convention for records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. I find this inadequate. With regard to 'authenticity of information', the section doesn't discussion when authenticity of information might be important, nor does it discuss risks of relying on information in which the authenticity is not assured. While it may well be true that this use of DNS has 'no specific additional security requirements', there are likely many DNS security issues which apply here and should be discussed here (possibly with reference to DNS specifications providing more general discussion of the security issues). In particular, this document recommends additional RRs be generated (section 13) but fails to discussion security implications and concerns with such generation. There likely should be some discussion of considerations as when this very public discovery mechanism should be used, as opposed to a discovery mechanism which only provides discovery to authorized entities. I think that portions of this document could be viewed as inappropriately supplanting per-protocol specifications of DNS SRV handling, and possibly RFC 2782 itself. I think the IANA registration would be better specified on the standard track, or in a BCP. I also think some of the market drivel (Section 21) should be removed. I would much prefer this to be reworked as a update or replacement of RFC 2782. I've read a number of reviews posted on the IETF list. I have general concerns similar to those posted by Dave Cridland and Ben Campbell. In short, this document seems to need more work. -- Kurt___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Who Wants an RFID Badge for the Upcoming IETF Conference?
Dr. Henning has asked us to install a system which will help participants identify themselves with their name and affiliation. If you want to know more about the raison d'être for the project please view this presentation (see[1]). Briefly: the purpose of the badge is to permit people (with names that may have unfamiliar spellings) to have their names transmitted to the chatrooms announcing their presance. Kindly email me your name and affiliation or better still just enter them in this database table right here : http://tech.groups.yahoo.com/group/ietf2008/database?method=reportRowstbl=1 Or better still if someone can provide us with the names of the attendees we can prepare the pertinent badges for them :) [1] http://www.mediafire.com/?sharekey=54ff8064285e58cfc74064dd4c81b78a52bb0458ee4d8af2 or http://www.mediafire.com/?gjmum2gntjx ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Nov 10, 2008, at 7:18 AM, Keith Moore wrote: John Levine wrote: As I said a few messages up in this string, although the structure of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't that mature yet and one of my goals was to make them interoperate equally well so, for example, if you find you're using cruddy ones you can easily switch to better ones. I suspect it will be very difficult to make IPv6 DNSxLs work anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use a different address for every SMTP conversation. Agreed. One might hope that the future will use DKIM domains and on- behalf-of tuples as an alternative to that of an IP address blocking list. Ideally, the on-behalf-of would be an opaque value assigned by the provider, that is changed whenever a problem is corrected. This would eliminate the need for coordination between those that run reputation services and the senders. Those that abuse this freedom would be at risk of finding their entire domain blocked instead. The problem that needs solved is how to block compromised systems, more than blocking individuals. Frankly, it would be best not to have any personably identifiable values used. Unfortunately, being able to detect misbehavior at a sufficient level to safely conclude whether an outbound MTA is poorly managed requires rather extensive infrastructure. This infrastructure is often several times larger than the typical infrastructure of a client being protected. These services address the problem of scaling email defenses. Assessments are fairly difficult when the MTA being judged has little volume, since even an occasional misidentification of NDN as spam might create a profile fairly similar to those created by bot- nets. Bot-nets represent a sizable portion of today's spam sources. IMHO, the goal of the black-hole list should be to inform ISPs and have them remove bad actors from their network and hopefully to encourage them to better monitor their own traffic. ISPs will not agree with this. Even the largest decoy infrastructure sees only a tiny fraction of the overall traffic. A desire to rapidly block any IP address that appears to be actively spamming provides bad actors a simple way to locate decoys and render the system less effective. While there are ways to deal with this problem, it both increases the infrastructure required, and the duration of a listing applied to problematic addresses. While there may be some concern that DNSxLs use A records as a flag, normally these records are limited to an address range of 127.255.255.255 - 127.0.0.2 (only 23 bits worth of data). It seems unlikely that the use of these IP addresses will lead to any problem. The reason for suggesting that the document be published as Informational has to do with there not being _any_ real experience yet in attempting to block IPv6 addresses. Routers will only be handling a faction of the total IP address space that IPv6 makes available. IPv6 DNSxL entries will not represent the same number of routes managed by routers. This would suggest that entire networks are to be blocked whenever a significant level of abuse is detected that warrants blocking. This would be a rather bunt tool. There are a few points that this draft attempts to answer in a reasonable way. The software used by the DNS servers is not going to change to support the IPv6 address space. The servers will continue in the same fashion as before. Instead of a query address of 127.0.0.2, this draft suggest the value :::7F00:2 to test the existence of the list. Until there is some greater experience in handling IPv6 address space, do not get ahead of the problem by concluding how this service is to resolve the practical challenges ahead. When a network handles a mixture of legitimate and abusive traffic, it may be impossible to cope with the volume of tracking data that will be required. After all, evidence MUST BE retained for everything blocked to squelch erroneous customer complaints and the occasional law suit threat. While SANs are getting bigger, to scale these systems for tracking addresses within an IPv6 network is unlikely to be economically all that practical. This might be wrong, but it should be less expensive for reputation services to use DKIM domains and an opaque on-behalf- of value instead. DKIM would also create less danger with respect to collateral blocking. MTAs may need to be equipped with crypto hardware to deal with foo signature abuse. At least MTAs should be able to rate limit any IP address sending foo signatures. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
On Fri, 14 Nov 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], Tony F inch writes: You also need the server to provide a verifiable TLS certificate. The vast majority of them are not. This problem is perhaps even harder to fix than the lack of DNSSEC. Just use DNSSEC and CERT records to do that. ... If self signed, look in the DNS for the CERT. Accept if signed and validated by DNSSEC. How does an application do accept if signed and validated by DNSSEC? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
In message [EMAIL PROTECTED], Pekka Savola writes: On Fri, 14 Nov 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], Tony F inch writes: You also need the server to provide a verifiable TLS certificate. The vast majority of them are not. This problem is perhaps even harder to fix than the lack of DNSSEC. Just use DNSSEC and CERT records to do that. ... If self signed, look in the DNS for the CERT. Accept if signed and validated by DNSSEC. How does an application do accept if signed and validated by DNSSEC? You validate the CERT RRset using the techniques in RFC 4033, 4034 and 4035. If the answer is secure then it was signed and validated. You the match offered cert to the CERT RRs using the information from RFC 4398. Do you need more detail or is that enough guidance? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
On Fri, 14 Nov 2008, Mark Andrews wrote: How does an application do accept if signed and validated by DNSSEC? You validate the CERT RRset using the techniques in RFC 4033, 4034 and 4035. If the answer is secure then it was signed and validated. You the match offered cert to the CERT RRs using the information from RFC 4398. Do you need more detail or is that enough guidance? I was interested in more detail, specifically, are there application interfaces an application could use, or every app need to implement validation using 4033-5 techniques (a lot of work, and most would probably do it wrong)? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
In message [EMAIL PROTECTED], Pekka Savola writes: On Fri, 14 Nov 2008, Mark Andrews wrote: How does an application do accept if signed and validated by DNSSEC? You validate the CERT RRset using the techniques in RFC 4033, 4034 and 4035. If the answer is secure then it was signed and validated. You the match offered cert to the CERT RRs using the information from RFC 4398. Do you need more detail or is that enough guidance? I was interested in more detail, specifically, are there application interfaces an application could use, or every app need to implement validation using 4033-5 techniques (a lot of work, and most would probably do it wrong)? There are a number of libraries available which can do dnssec validation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SMTP+TLS to MXs, was Re: Comments on Draft IRTF ASRG DNSBL - 07
In message [EMAIL PROTECTED], Mark Andrews writes: In message [EMAIL PROTECTED], Pekka Savola write s: On Fri, 14 Nov 2008, Mark Andrews wrote: How does an application do accept if signed and validated by DNSSEC? You validate the CERT RRset using the techniques in RFC 4033, 4034 and 4035. If the answer is secure then it was signed and validated. You the match offered cert to the CERT RRs using the information from RFC 4398. Do you need more detail or is that enough guidance? I was interested in more detail, specifically, are there application interfaces an application could use, or every app need to implement validation using 4033-5 techniques (a lot of work, and most would probably do it wrong)? There are a number of libraries available which can do dnssec validation. And if you want to off load the validation you can used AD + TSIG. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Can we have on NAT66 discussion?
On Thursday 13 November 2008 21:30:39 ext Darrel Lewis (darlewis), you wrote: DL Port/Overload NAT for IPv4 (NAT:P) has security benefits in that it requires explicit configuration to allow for inbound unsolicited transport connections (via port forwarding) to 'inside' hosts. This mimics many of the default policies on most firewalls, hence the confusion. Note that can also cause security issues elsewhere in the network. The loss of information of the identity of the source host can cause address filtering in the network to effect other devices than just the one intended. That's not _quite_ true. The truth is that many boxes that are NATs also are firewalls. A full cone NAT, with UPnP IGD (or NAT-PMP) is barely providing any security protection to the host. And many NATs have the so-called DMZ function whereby they'll forward all incoming traffic to a specified internal host. Besides, if you don't have a public IP address, you are not addressable from the Internet. Whether you have a NAT, a set of proxies or no connection, is irrelevant - the lack of addressability is your protection, not the NAT. If you have public space internally, you can also NATs outbound, and not inbound. Then you NAT provides obviously no protection at all. A firewall would. DL I'm wondering if this is written down somewhere, because both of the above points seem to be argued over and over again, without people being genererally educated about them. We have the IPv6 security RFC. We have the IPv6 simple CPE security and the NAT security I-Ds. DL I would argue that stateless filtering (e.g. access control lists) are even more common than firewalls and are the single most widely used network security control. But the main point is that firewalls ( statefull (flow based) filtering that usually have default policies), are orthogonal to address translation. They just happen to occur at the same point in the topology in many networks. Yes. And that's the whole point: the firewall function is providing some kind of protection. Not the NAT function. -- Rémi Denis-Courmont Maemo Software, Nokia Devices RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Second Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms
with Cryptographic Message Syntax) to Proposed Standard Reply-to: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Using SHA2 Algorithms with Cryptographic Message Syntax ' draft-ietf-smime-sha2-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-11-27. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is the second Last Call for this specification. After completion of IETF Last Call, the working group decided to simplify the encoding of parameters which changes the bits on the wire. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16033rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
