Re: Would someone help the secretariat figure out why they cannot route to teredo addresses?
On 1-okt-2007, at 19:50, Sam Hartman wrote: This is annoying because glibc's source address selection algorithm seems to prefer teredo addresses to v4 addresses. So, I get really bad response times to www.ietf.org when using teredo. It would help if vendors implemented the RFC 3484 policy table so administrators can override this. (AFAIK, only (Free)BSD and Windows support this.) Based on the responses to the ticket, it was not entirely clear if the people at NSS understood how teredo differs from a normal IPV6 address. I just don't have time to work with them to debug the problem. Is there someone out there with significant IPV6 experience who can reproduce the problem and who would be willing to work with NSS to resolve? I'm not currently in the position to test Teredo, but I suspect there is more going on. For instance, I can't reach the IETF or ARIN using 2001:1af8:2:5::2. The problem seems to be with OCCAID, which provides IPv6 connectivity to both. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote: Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. That assumption has always been wrong. Not in my experience. Actually, there are two separate things here. One, is implementation/ product, the other is configuration and device administration. I'm not sure how your average user would separate the two from a practical standpoint, and it really doesn't matter. I'm aware of at two products in the last few months that, in production deployment forced TCP switch-over, only to find that this broke name resolution completely for a large pool of subscribers. In addition, in my own experience, more often than not when folks clamp down firewall policies, in particular in enterprise or restricted space, they often deny all TCP/53 to address spaces (in one case the culprit for the brokenness above). Another common place to see policies that block TCP/53 is roaming access points captive user environments. E.g., SSH tunneling over DNS was easy enough over UDP. To further support my statement, just google for +firewall policy +TCP/53 +DNS, here are a few examples: http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf Service: The enabled service is DNS (domain-udp, port 53/udp). Firewall-1’s DNS service by default contains both domain-udp (53/udp) and domain-tcp (53/tcp). We have removed domain- tcp from the object definition, on the grounds that we will not be permitting zone transfers. It will be necessary to watch carefully since removing domain-tcp also means that long dns-queries will not be supported. It is important to note that this will not work unless “Accept UDP replies” is enabled on the Firewall-1 Security Properties screen. Without “Accept UDP replies” enabled, the queries will still be allowed through the firewall, but the replies will be dropped on the firewall. http://security.ucdavis.edu/basic_firewall_rules.pdf: Allow DNS (UDP 53) to internal DNS server – If the unit runs internal DNS servers this rule is recommended. The rule is needed if a Windows Active Directory server is hosted on the internal network. You must permit TCP 53 for zone transfer capability, however this permission should not be applied by default. Right or wrong, it's quite common. I would also dispute the many above. Most firewalls actually handle the transition to TCP perfectly fine. There are the odd few that are misconfigured. When that happens people complain because nameservers resolution fails. Either the dataset is fixed or the firewall is fixed. I'd be quite interested in any pointers you might have to empirical evidence supporting this position. I don't believe it's an odd few that are misconfigured, I believe it's often done as a conscious effort. -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote: I'm not blaming the victim, I'm pointing out the contributory negligence on behalf of the ISP that is supplying the attacker bandwidth. BCP 38 is over 7 years old now. The time has past where you can blame the hardware vendors for lack of support. The blame now has to be squarely brought down on the ISP's that have failed to deploy BCP 38. Really? How many ISPs are you aware of that have *decommissioned* every piece of routing gear in their network in the past 7 years? The ugly bit here is that routers usually are pushed further and further to the edge of the network, until they finally fall off. The closer to the edge they get to the edge, the less feature capability they usually have, while all the more you need them. Furthermore, it's pretty much impossible to explicitly filter based on sources from large peers with lots of routes and lots of churn, or ever large customers, for that matter. Dynamically generated feasible path RPF models are the best solution for this, but there's little (no?) support. And even those models are derived based on RIB data, which means route policy essentially dictates what you'll accept for both data plane and control plane. But wait, where's the authoritative source for who owns what prefixes, and who's permitted to originate/transit what prefixes? BTW: Even NIST Guidelines on Firewalls and Firewall Policy recommends blocking TCP/53, except for external secondaries. -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote: Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application =20 points assume things like DNS resolution will only be UDP/53 transactions. That assumption has always been wrong. Not in my experience. I repeat. The ASSUMPTION as ALWAYS been wrong. From day one the DNS specified fall back to TCP for QUERY. Actually, there are two separate things here. One, is implementation/ product, the other is configuration and device administration. I'm not sure how your average user would separate the two from a practical standpoint, and it really doesn't matter. I'm aware of at two products in the last few months that, in production deployment forced TCP switch-over, only to find that this broke name resolution completely for a large pool of subscribers. It still doesn't mean that many are badly configured only that some are badly configured. In addition, in my own experience, more often than not when folks clamp down firewall policies, in particular in enterprise or =20 restricted space, they often deny all TCP/53 to address spaces (in one case the culprit for the brokenness above). And I presume they adjusted the policy once they discovered how idiotic it is. Another common place to see policies that block TCP/53 is roaming access points captive user environments. E.g., SSH tunneling over DNS was easy enough over UDP. I didn't say that it didn't occur. Some people are stupid. To further support my statement, just google for +firewall policy +TCP/53 +DNS, here are a few examples: http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf Service: The enabled service is DNS (domain-udp, port 53/udp). =20 Firewall-1=92s DNS service by default contains both domain-udp (53/udp) and domain-tcp (53/tcp). =20 We have removed domain- tcp from the object definition, on the grounds that we will not be =20 permitting zone transfers. It will be necessary to watch carefully since removing domain-tcp also means =20 that long dns-queries will not be supported. It is important to note that this will not work =20 unless =93Accept UDP replies=94 is enabled on the Firewall-1 Security Properties screen. Without =20 =93Accept UDP replies=94 enabled, the queries will still be allowed through the firewall, but the replies =20 will be dropped on the firewall. So. It just means they intend to live dangerously. This policy will bite them at some point. http://security.ucdavis.edu/basic_firewall_rules.pdf: Allow DNS (UDP 53) to internal DNS server =96 If the unit runs internal =20= DNS servers this rule is recommended. The rule is needed if a Windows Active Directory =20= server is hosted on the internal network. You must permit TCP 53 for zone transfer =20 capability, however this permission should not be applied by default. Someone should talk to ucdavis.edu and get this idiocy pulled. Right or wrong, it's quite common. I would also dispute the many above. Most firewalls actually handle the transition to TCP perfectly fine. There are the odd few that are misconfigured. When that happens people complain because nameservers resolution fails. Either the dataset is fixed or the firewall is fixed. I'd be quite interested in any pointers you might have to empirical evidence supporting this position. I don't believe it's an odd few that are misconfigured, I believe it's often done as a conscious effort. Because there are lots of recursive and authoritative nameservers out there behind firewalls that get it right. I've seen many more complaints about UDP packets 512 bytes being blocked than complaints about fallback to TCP failing. Most people actually do the right thing without thinking about it. The allow TCP out to anything this includes DNS servers. Most allow both UDP and TCP in to their nameservers. This is the silent majority. Mark -danny= -- 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://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 2, 2007, at 1:41 AM, Mark Andrews wrote: Someone should talk to ucdavis.edu and get this idiocy pulled. And NIST, and many many others.. Because there are lots of recursive and authoritative nameservers out there behind firewalls that get it right. I've seen many more complaints about UDP packets 512 bytes being blocked than complaints about fallback to TCP failing. Most people actually do the right thing without thinking about it. The allow TCP out to anything this includes DNS servers. Most allow both UDP and TCP in to their nameservers. This is the silent majority. Again, any pointers empirical data along these lines would be appreciated. -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote: I'm not blaming the victim, I'm pointing out the contributory negligence on behalf of the ISP that is supplying the attacker bandwidth. BCP 38 is over 7 years old now. The time has past where you can blame the hardware vendors for lack of support. The blame now has to be squarely brought down on the ISP's that have failed to deploy BCP 38. Really? How many ISPs are you aware of that have *decommissioned* every piece of routing gear in their network in the past 7 years? The ugly bit here is that routers usually are pushed further and further to the edge of the network, until they finally fall off. The closer to the edge they get to the edge, the less feature capability they usually have, while all the more you need them. Again, its the ISP's *choice* to use such equipment. At some point someone that has been attacked will sue the connecting ISP's from which the packets originated and I wouldn't be suprised to see the ISP being fined or otherwise penalised. Furthermore, it's pretty much impossible to explicitly filter based on sources from large peers with lots of routes and lots of churn, or ever large customers, for that matter. Dynamically generated feasible path RPF models are the best solution for this, but there's little (no?) support. BCP 38 is about *everyone* filtering as close to the source as possible. You do your part and your peer does their part. And even those models are derived based on RIB data, which means route policy essentially dictates what you'll accept for both data plane and control plane. But wait, where's the authoritative source for who owns what prefixes, and who's permitted to originate/transit what prefixes? BTW: Even NIST Guidelines on Firewalls and Firewall Policy recommends blocking TCP/53, except for external secondaries. Even NIST can get it wrong. -danny -- 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://www1.ietf.org/mailman/listinfo/ietf
RE: [secdir] draft-aboba-sg-experiment-02.txt
Hi Lakshminath, your comments solve my concerns, mostly. I understand your reasons and actually am not sure I have a really better idea. So please consider my comments rather as personal concerns, not comments that need to be resolved: #2: I still do not feel 100% comfortable with the fact that the SG will introduce a new second extension after the second BOF; on the other hand, as the SG is at the discretion of the AD, there should be no harm. #3: I fully understood the part with the SG ... MUST NOT include milestones relating to development of a protocol specification, but actually let me envision the following scenario: People start to work in a SG, e.g. on charter and requirements and as they most probably also already have a solution in mind (e.g. they made a prototype or even full implementation) they will in parallel prepare the other drafts. Ok they can not track this via milestones, but maybe this is not perceived as so critical by them and the current experiment draft also actually allows them to submit I-Ds in the SG about protocols etc. - just like a normal WG. (and probably to submit such I-Ds SHOULD NOT be forbidden in the experiment, as it can help to work on the requirements when you have an example solution to look at, and actually I would hate to stop people to think or work in any direction - just for the sake of a process...) So you see, this distinction line between SG and WG feels very faint to me and maybe might also initiate an automatism to _always_ go from SG to WG, because so much work has already been done... However, having that said, I believe that you can't make a process 100% foolproof (at least not one that you actually want to really use in real life) and hey that's what an experiment is for, so I will be fine to try it. Again as a summary: I think it's a great idea and would hum for progressing the draft and the experiment. - Tobias -Original Message- From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 5:55 AM To: Tobias Gondrom Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [secdir] draft-aboba-sg-experiment-02.txt Hi Tobias, Many thanks for your review. Please see inline for my thoughts on your observations. On 10/1/2007 9:39 AM, Tobias Gondrom wrote: Hello, 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 document described an RFC3933 experiment in forming a Study Group prior to Working Group formation. As such I agree with the authors that there are no additional specific security considerations as also discussed in RFC3933. Aside from the Security Review, I have three comments: 1. editorial comment to section 1: s/those who have no followed the/ those who have not followed the We'll fix this in the revision. 2. comment to section 2: Section 2 states that: If at any point, including after a first or second BoF session, ... the IESG MAY propose that a Study Group be formed. This sounds to me like partially conflicting with RFC2418, which clearly states that an absolute maximum of two BOFs are allowed for a topic. This would implicate that if a Study Group was formed after the second BOF, it would have to directly lead to a WG (or be abandoned) as it can not go back to BOF. I would propose to change this to that a Study Group may be initiated after the first BOF but not after the second to prevent this conflict. (The second BOF is already an extension and we should not add the Study Group as a second extension to the system. People should be pretty well prepared at a second BOF to get either a Yes or No -- and if they are not ready for a decision by then, another second extension may probably also not help.) My take is that after the SG it is a WG or nothing. The sponsoring and other ADs would have the opportunity to observe the SG in progress just as they would do a BoF and can assess whether to form a WG or not. With that clarification, does the current wording sound alright? So, proposal to change the line in section 2 accordingly: s/including after a first or second BoF session/including after a first BoF session I.e. if a first BOF does not lead to the anticipated results (WG: yes/no decision), the appropriate mechanism for the AD should be to decide whether s/he wants to use this experiment or run straight with the second BOF as defined in the process. With the study group the second BOF could be initiated after the Study Group has concluded if the AD does not want to go to WG directly
Re: IPv4 to IPv6 transition
Hi All Just an input about the NAT issue handled here. The 'war' against NAT is senseless before succeeding the one against IPv4. I mean, as far as the v4 protocol runs on our networks, NAT will remain as a useful tool for those who need it, of course for specific applications. In developing countries for example where IPv6 entry is very slow -add to a scarcity of IPv4 addresses- we are always using NAT, and are happy to do so as: 1- No enough IPv4 addresses 2-No need for the specific applications for those networks 3-No alternative solution currently 'in the hands'. Thanks Philemon - Original Message - From: Hannes Tschofenig [EMAIL PROTECTED] To: Keith Moore [EMAIL PROTECTED] Cc: Stephen Sprunk [EMAIL PROTECTED]; ietf@ietf.org; Paul Hoffman [EMAIL PROTECTED] Sent: Friday, July 13, 2007 9:11 PM Subject: Re: IPv4 to IPv6 transition Hi Keith, Keith Moore wrote: Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. Ciao Hannes Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Tue, 2 Oct 2007 01:48:36 -0600 Danny McPherson [EMAIL PROTECTED] wrote: Again, any pointers empirical data along these lines would be appreciated. I said this awhile back: http://www.merit.edu/mail.archives/nanog/msg02196.html As a datapoint I ran some tests against a reasonably diverse and sizeable TLD zone I work with in another forum. I queried the name servers listed in the parent to see if I could successfuly query them for their corresponding domain name they are configured for using TCP. Out of about 9,300 unique name servers I failed to receive any answer from about 1700 of them. That is a bit more than an 18% failure rate. I think I overcompensated as I later found what looked like BIND 8 servers being unresponsive for multiple TCP queries in queue. I let the numbers stay, since the percentage of those servers were fairly small and, well, they were BIND 8 and probably have other problems anyway. :) John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
The shortage of IPv4 addresses in developing countries in a red herring. All one has to do is apply for them from the RIR. Getting a service provider to route them is a different problem, especially when they profit from running your traffic through their NAT. Ray -Original Message- From: philemon [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 6:40 AM To: Hannes Tschofenig; Keith Moore Cc: Stephen Sprunk; ietf@ietf.org; Paul Hoffman Subject: Re: IPv4 to IPv6 transition Hi All Just an input about the NAT issue handled here. The 'war' against NAT is senseless before succeeding the one against IPv4. I mean, as far as the v4 protocol runs on our networks, NAT will remain as a useful tool for those who need it, of course for specific applications. In developing countries for example where IPv6 entry is very slow -add to a scarcity of IPv4 addresses- we are always using NAT, and are happy to do so as: 1- No enough IPv4 addresses 2-No need for the specific applications for those networks 3-No alternative solution currently 'in the hands'. Thanks Philemon - Original Message - From: Hannes Tschofenig [EMAIL PROTECTED] To: Keith Moore [EMAIL PROTECTED] Cc: Stephen Sprunk [EMAIL PROTECTED]; ietf@ietf.org; Paul Hoffman [EMAIL PROTECTED] Sent: Friday, July 13, 2007 9:11 PM Subject: Re: IPv4 to IPv6 transition Hi Keith, Keith Moore wrote: Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. there are a couple of problems with this analysis: one is that it considers only application protocols that are in widespread use. there are lots of applications that are used by limited communities that are nevertheless important. Namely? and of course, since NATs are so pervasive, most of the applications that are in widespread use have been made to work with NAT (often at tremendous expense, and reduced reliability). Could you explain the tremendous expense a bit more? another problem is that it only considers current applications. a big part of the problem with NAT is that it inhibits the development/deployment of useful new applications. As Phillip stated, I don't see the problem with future applications. Compare this with the security aspects that are taken care of much more than before when developing new applications NAT traversal is just another thing to think about as a protocol designer. Ciao Hannes Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On 2-okt-2007, at 15:05, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. Yellow herring? There are five RIRs that serve different parts of the world. Each of them will give people pretty much all the addresses they reasonably need if they pay the RIR fees (starts at a few thousand dollars a year) and maybe qualify for some minimum size. There may be people who can't afford this, or people who can't afford to buy the connectivity to make these addresses useful, but the address space in and of itself is not the issue. Point in case: China. By the turn of the century, they only had 7.57 million addresses of the 1.6 billion in use at that point (as far as I can determine easily right now, there may be some differences) but today it's 130 million of 2.55 billion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
should have been is -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:06 AM To: Ray Plzak Cc: philemon; Hannes Tschofenig; Stephen Sprunk; ietf@ietf.org; Paul Hoffman Subject: Re: IPv4 to IPv6 transition Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Mon, 1 Oct 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. [1] http://www.iana.org/assignments/dscp-registry -- 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://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching)
It seems that policy should be scenario / use case / mission dependent, and consequently apply to a number of applications. (And thus be application independent). Bonnie L. Gorsic Technical Fellow SoS Architecture Engineering 714-762-4906 (desk) -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 8:35 PM To: Jun-ichiro itojun Hagino Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching) Jun-ichiro itojun Hagino wrote: What a timely thread. I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. perhaps, but having the policy be application-independent doesn't make sense either. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Would someone help the secretariat figure out why they cannot route to teredo addresses?
Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez écrit: Hi. I opened a ticket with the secretariat a few weeks ago complaining that I cannot reach www.ietf.org using a teredo address either allocated through the Microsoft Teredo server or the Debian teredo server. This is annoying because glibc's source address selection algorithm seems to prefer teredo addresses to v4 addresses. So, I get really bad response times to www.ietf.org when using teredo. To make a long short, that depends on your glibc version. As far as I remember, RFC3484 was implemented in version 2.4. Configurable policy in version 2.5, and Teredo in the default policy only very recently. this really shows that the approaches with policy table is very against of KISS principle... itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
From: Danny McPherson [EMAIL PROTECTED] where's the authoritative source for who owns what prefixes This, one could imagining putting together. and who's permitted to originate/transit what prefixes? This is a whole different kettle of bits. For one thing, there's no guaranteed-uniquely-definitive answer: entity A might have one idea of how it wants packets to flow from it to a given other entity B (say, 'don't use provider X because we despise them'), but entity B might disagree. Who should win that dispute? So the whole notion of 'allowed to transit' is a potential tussle space; mind, I'm not saying there always will be this sort of issue, but it's *possible*. Second, you're talking about potentially orders of magnitude more data: for each destination, there are worldwide likely hundreds (or more) of ISP's which are likely to be viable backbone transits. (By 'backbone transit', I mean ISP's/AS's which are not even directly connected to the organization which is the source or destination of the packets; e.g. customer A is connected to ISP p which is connected to ISP q which is connected to ISP r which is connected to customer B; q is a 'backbone transit'.) With ISP's which are directly connected with a customer, one can assume that there's an implicit authorization, but what about steps past that? If one further assumes that by p connecting to q, p is transitively authorizing q (with respect to A), then that can be done with straightforward (albeit complex and expensive) security on routing. However, if you go that way, then you lose the ability for A to make assertions about which q's are not acceptable. If you add that back in as a policy knob, then you're back to potentially orders of magnitude more data. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
Joao == Joao Damas [EMAIL PROTECTED] writes: Joao It does indeed as Stephane pointed out. Opening up your Joao resolver so you can server roaming users, without further Joao protection, is, at best, naive. I'd appreciate it if you took Paul's comments a lot more seriously and looked at whether the dnsop view on this issue extends to other parts of the ietf. To the extent that it does not, please engage in a discussion designed to build consensus rather than assertions that someone who disagrees with you is naive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo()and searching)
Gorsic, Bonnie L wrote: It seems that policy should be scenario / use case / mission dependent, and consequently apply to a number of applications. (And thus be application independent). it's normal for policy to be different from one application to another. some applications are permitted by policy, others are forbidden, others are permitted with restrictions. also, it is difficult to generalize policy specification to the point that it can be independent of all applications, because sometimes there is a subtle interaction between policy and the application. for example, many sites have mail filtering policies that hinge on subtleties of SMTP protocol responses and DNS query results. it doesn't make sense to try to specify those in an application-independent fashion. that said, a coarse specification of policy that could be applied to some applications would still be useful. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. I would expect most applications to use only AI_SECURE_CANONNAME or AI_CANONNAME_SEARCH_DEFAULT. AI_CANONNAME_SEARCH_DEFAULT would come with a system-wide knob attached. But perhaps we should just say that AI_SECURE_CANONNAME should behave like what I called AI_CANONNAME_SEARCH_DEFAULT. Some applications might offer app-specific configuration knobs to specify the use of any of the other AI_CANONNAME_SEARCH_* flags. _Most_ apps would not. The availability of choices at the API level != a plethora of application knobs, just the possibility thereof. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Ray, I don't think it's quite fair to refer to ostriches when ARIN is already on record: http://www.arin.net/v6/v6-resolution.html Also, for those who like to see things in real time, there's always http://penrose.uk6x.com/ Regards Brian Carpenter University of Auckland On 2007-10-03 02:47, Ray Plzak wrote: Head in the sand is substituting the statement shortage of IP addresses for the condition of the inability to use the addresses (take your pick when it comes to infrastructure deficiencies). Ray -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 9:32 AM To: ietf@ietf.org Subject: Re: IPv4 to IPv6 transition On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
Pekka, [FYI I've already indicated my support for this draft in a message sent to the IESG.] On 2007-10-03 03:11, Pekka Savola wrote: On Mon, 1 Oct 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. I think this is really not a valid interpretation. It's very common in the IETF to produce the first version of operational recommendations as Informational, with the possibility of producing a later version as BCP when there's successful operational experience. I believe that this draft, and RFC 4594, are in that category. IMHO they do not significantly change the implementation requirements for the various Proposed Standard diffserv PHBs; they add configuration recommendations for those PHBs, which is a perfectly legitimate thing for an Informational RFC. To be clear, the notion of reclassifying diffserv traffic at a domain boundary is a fundamental part of the diffserv architecture, and remapping diffserv classes into treatment aggregates, as this draft describes, is just an example of such reclassification. This draft does not change the diffserv architecture and does not redefine any of the standards track PHBs. To quote an example from the text: Traffic in the Real Time treatment aggregate should be carried in a common queue or class with a PHB as described in RFC 3246 [11] and RFC 3247 [12]. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. Not until there is significant operational feedback, which is still a year or three in the future. I don't see that this draft, or RFC 4594, is significantly different in that respect from, say, RFC 4472. Brian [1] http://www.iana.org/assignments/dscp-registry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Spammers answering TMDA Queries
The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. This would mean that a legitimate user of a list that uses TDMA would get a TDMA query once a year if they are not subscribed to any ietf.org mail list. There is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: Russ wants to know how many people have responded to the TMDA challenge but are not on any IETF mailing list. 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
At 6:49 PM -0400 10/2/07, Russ Housley wrote: 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? How was that 20% number guessed at?. If 200 spammers (or even 20!) were on the TDMA list, we should be seeing tons of spam on the lists; so far, we are not. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
On Tuesday 02 October 2007 18:49, Russ Housley wrote: The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. This would mean that a legitimate user of a list that uses TDMA would get a TDMA query once a year if they are not subscribed to any ietf.org mail list. There is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: Russ wants to know how many people have responded to the TMDA challenge but are not on any IETF mailing list. 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? Randomly unsubscribing non-abusing mailing list subscribers is unlikely to be an effective spam fighting tool. If people spam an IETF list, unsubscribe them. If not, don't. It's not clear to me what problem you are trying to solve. Scott K ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Spammers answering TMDA Queries
Sounds reasonable to me. Tdma for personal email protection is rude and unacceptable. For mailing lists it is entirely acceptable. Cost far outweighs benefit as the inconvenience to the single sender is much less than the benefit to the community. Should also consider if spf or dkim checks could cull the paypal spam. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 04:12 PM Pacific Standard Time To: ietf@ietf.org Subject:Spammers answering TMDA Queries The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. This would mean that a legitimate user of a list that uses TDMA would get a TDMA query once a year if they are not subscribed to any ietf.org mail list. There is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: Russ wants to know how many people have responded to the TMDA challenge but are not on any IETF mailing list. 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Paul Hoffman wrote: At 6:49 PM -0400 10/2/07, Russ Housley wrote: 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) Thoughts? How was that 20% number guessed at?. If 200 spammers (or even 20!) were on the TDMA list, we should be seeing tons of spam on the lists; so far, we are not. Maybe they're just harvesting addresses? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Random addresses answering TMDA Queries
The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. Isn't there an engineering principle that if something is broken, you don't fix it by breaking it even worse? Naive challenge/response systems like TMDA never worked very well, and on today's Internet they've become actively dangerous. About 90% of all email is spam, and just about all spam has a forged return address at a real domain, often taken from the spam list. This means that most TMDA challenges go to innocent bystanders. Given the volume of spam, it also means that even though only a small fraction of addresses send autoresponses, that's enough to badly pollute any system that uses C/R for validation. If you look at the bogus addreses, I would be rather surprised if they weren't mostly random non-spammers that either auto-acked their way in, or else are people like me who ack all challenges because it's the easiest way to get other people's C/R crudware to shut up. There are plenty of workable ways to filter spam. I've found that, ironically, it is particularly difficult to get people to set up effective filters in environments full of grizzled old nerds. A lot opinions about the nature of spam and filters seem to have been formed in about 1999 or 2000 and haven't been re-examined since then, so when I suggest, e.g., that well chosen DNSBLs can knock out 80% of the spam with essentially no false positives, which is true, they don't believe it. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Random addresses answering TMDA Queries
On Oct 2, 2007, at 6:14 PM, John Levine wrote: The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. Isn't there an engineering principle that if something is broken, you don't fix it by breaking it even worse? Naive challenge/response systems like TMDA never worked very well, and on today's Internet they've become actively dangerous. About 90% of all email is spam, and just about all spam has a forged return address at a real domain, often taken from the spam list. This means that most TMDA challenges go to innocent bystanders. Given the volume of spam, it also means that even though only a small fraction of addresses send autoresponses, that's enough to badly pollute any system that uses C/R for validation. If you look at the bogus addreses, I would be rather surprised if they weren't mostly random non-spammers that either auto-acked their way in, or else are people like me who ack all challenges because it's the easiest way to get other people's C/R crudware to shut up. There are plenty of workable ways to filter spam. I've found that, ironically, it is particularly difficult to get people to set up effective filters in environments full of grizzled old nerds. A lot opinions about the nature of spam and filters seem to have been formed in about 1999 or 2000 and haven't been re-examined since then, so when I suggest, e.g., that well chosen DNSBLs can knock out 80% of the spam with essentially no false positives, which is true, they don't believe it. Agreed. Email related filtering mechanisms are often broken and can be dangerous. Recipients without DNSBLS are likely seeing only a small percentage of valid email. Of the junk hitting MTAs, more than half is likely to contain a copy of spam reflected off someone's server. IETF lists have recently created their share of this traffic. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
On 2007-10-03 11:49, Russ Housley wrote: The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. This would mean that a legitimate user of a list that uses TDMA would get a TDMA query once a year if they are not subscribed to any ietf.org mail list. There is no TDMA query for people who are on at least one ietf.org mail list. Here is the info that I have: Russ wants to know how many people have responded to the TMDA challenge but are not on any IETF mailing list. 1025 mail addresses have confirmed their address. I would bet that at least 20% of the confirmed are spam addresses (or autoconfirmed addresses) A little history... I manually scanned the TMDA white list about a year ago, or rather I scanned the ~700 addresses that had then confirmed themselves. I didn't keep the relevant files on grounds of privacy protection, but I recall that around 30 of the addresses were self-evidently spammers that we removed manually; there were quite a lot that were self-evidently genuine. However, there were a large number which just couldn't be classified by inspection. I can easily believe the 20% estimate. Speaking personally, I think annual reconfirmation is quite reasonable. The message sent to the user should make it clear that it is an annual process. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
dedicate to ostriches... http://www.apple.com/en/downloads/dashboard/networking_security/ ipv420.html On 2007/10/02, at 22:32, Tim Chown wrote: On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote: Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. that has to rank as one of the most bizarre statements that's ever been made on the ietf list. More of an ostrich than a herring? .==._ / ., .`. /__(,_.-' || `/||| / ||| \||| ~ ~ |\ ~~!)~~~ Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- Ruri Hiromi [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Random addresses answering TMDA Queries
IESG list. The chain: Spamassassin - TMDA - mailman moderation basically does the job just fine. Oh, I hadn't realized that Spamassassin was in front. Yes, that should help a lot, since I expect that the contents of legit mail to IETF lists is rather unlike the contents of most spam. On the other hand, I run the ASRG list, and I'm seeing several hundred spams a day land in the mailman moderation queue. If I don't clean it out a couple of times a week, the list of stuff to delete gets so big that my web browser times out trying to load it. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Random addresses answering TMDA Queries
On 2007-10-03 14:14, John Levine wrote: The Secretariat tells me that Spammers are responding to TDMA queries so that their mail goes through. They have made the suggestion that we clear the list of people once per year. Isn't there an engineering principle that if something is broken, you don't fix it by breaking it even worse? Naive challenge/response systems like TMDA never worked very well, John, The IETF uses Spamassassin before mail ever hits TMDA, so most of the readily detected junk never gets there. From the time I was watching what was happening with TMDA at ietf.org, the problems you describe just weren't happening; what was happening was that literally 99% of the spam that survived Spamassassin was getting caught. That's a serious estimate from the impact of TMDA on the IESG list. The chain: Spamassassin - TMDA - mailman moderation basically does the job just fine. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Ray Plzak wrote: The shortage of IPv4 addresses in developing countries in a red herring. All one has to do is apply for them from the RIR. Getting a service provider to route them is a different problem, especially when they profit from running your traffic through their NAT. ..or especially when a politically repressive government encourages ISPs to provide addresses through NAT because a) they can control content access better (by tricks such as transparent DNS proxies on the NAT box) and b) because makes it more difficult for dissident web site to pop up right and left. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
