Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Tue, Oct 02, 2007 at 12:40:31PM -0400, Sam Hartman [EMAIL PROTECTED] wrote a message of 17 lines which said: 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. OK, since I agree with Joao Damas on this point, let me rephrase it (again) without harsh words. Everyone took Paul Hoffman's and John Klensin's comments seriously. But these comments have a big flaw, they jump from the (legitimate) use case to a specific (and bad) solution. John Klensin's message wasted many bytes describing the (well known) problem instead of trying to see if the current I-D properly describes the solutions. Everyone agrees that there is a very real and very legitimate use case for roaming users to *not* use the default DNS resolver of the current access point (see RFC 4925, section 2.5.2 for a typical reason). But suggesting ORNS (Open Recursive Name Servers) for the solution to this issue is, indeed, a bad idea (do note I did not say the N word), for the reasons explained in draft-ietf-dnsop-reflectors-are-evil-04.txt (reflections attack). There are other solutions to this issue and lists have already been given in this thread *and* in the I-D we discuss. These solutions are TSIG, local caching resolvers and VPN. May be there is an editorial problem if they are not well explained but the I-D does completely cover the issue of romaing users. ___ 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?
Rémi Denis-Courmont wrote: 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. Because Teredo is not mentioned in RFC3484, I expect many other RFC3484 implementations do have the same issue. Unfortunately, even if they don't have Teredo support themselves, they should still recognize the prefix for source address selection... I did write an I-D to allocate one new prefix, but then I realized that the revised RFC3484 draft work already mentioned it, so I did not bother submitting it. Do you mean this I-D ? http://tools.ietf.org/id/draft-arifumi-ipv6-rfc3484-revise-00.txt This one includes mainly minor changes to RFC 3484. I tried to talk about this I-D at Prague, but I couldn't have time there. Though this I-D is expired now, I want to put this on the table again. Do you have any comments about this I-D ? Now that we have 6man wg, is it a good idea to move from intarea to 6man ? Thanks. -- Arifumi Matsumoto IP Technology Expert Team Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [secdir] secdir review ofdraft-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. The IETF has delegated this to the IANA and the RIRs. So far, the RIRs have not done anything more than keep the antiquated whois directory functioning. I use the word antiquated in reference to whois directory services not because of the query protocol, but because of its origins as a way of auditing network users in order to justify budget allocations back in ARPANET days. Since that time, there has never been a serious attempt to rethink the purpose and scope of the IP addressing whois directory. One wonders whether the vastness of the IPv6 address space is sufficient change for the IETF to write some guidance to the RIRs regarding the purpose and scope of a whois directory. Or maybe some other method of signalling the ownership of address prefixes. and who's permitted to originate/transit what prefixes? The RIRs have taken a stab at this problem with route registry services but it has never gotten significant support from ISPs. Since the RIRs delegate short prefixes to ISPs, who then may delegate longer prefixes in some way, the chain of permission to originate/transit, originates with the RIRs. Is a new protocol needed for this to work right? Or is there simply not enough demand. Note that some RIRs such as RIPE, attempt to maintain a fairly detailed route registry database as part of their whois directory. 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'.) We have the technology to deal with orders of magnitude more data, assuming that the task is delegated to servers, not to routers. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
Brian, My comment was regarding a head in the sand approach when it comes to the recurring themes that the developing world can't IP address space, whether it is v4 or v6. The fact is that they can get it from the RIR like those in the developed regions can get it from their RIRs. The real problem, in other words, putting head in sand, is to substitute this address space access issue for the real one of what can the recipients of the address space do with it when they get, particularly if they have no hardware to run it on, no electricity to power it, and no upstream willing to route it. It is those issues that need to be hit head on if the Internet is to really grow in the developing regions of the globe. Ray -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 4:39 PM To: Ray Plzak Cc: Tim Chown; ietf@ietf.org Subject: 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: IPv4 to IPv6 transition
correction, http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html let me know what do you think about it :-) Regards, On 2007/10/03, at 11:24, Ruri Hiromi wrote: 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 --- Ruri Hiromi [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html hi Ruri , well, i could imagine what its good for , but an english version would be appreciated ;) cheers Marc -- Marc Manthey - LET - research + deployment D- 50672 Cologne Hildeboldplatz 1a web: http://www.let.de my xing profile https://www.xing.com/profile/Marc_Manthey phone mobile: 0049.221.355.80.32 0049.177.341.54.81 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Wed, Oct 03, 2007 at 07:55:40PM +0900, Ruri Hiromi [EMAIL PROTECTED] wrote a message of 64 lines which said: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html ^^ Many webmasters still have not read RFC 4646 :-( let me know what do you think about it :-) Any translation in my own language? For english, Google suggests: IPv4 depletion clock 2.0 Empty circumstance of the IPv4 address space which IANA has managed and remaining days to depletion expectation day, it can look through the IPv4 address (presumption) and the like at present time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
courtesy of google translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.apple.com%2Fjp%2Fdownloads%2Fdashboard%2Fnetworking_security%2Fipv420.html+langpair=ja%7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Tony Hansen [EMAIL PROTECTED] Marc Manthey wrote: On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html well, i could imagine what its good for , but an english version would be appreciated ;) ___ 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 Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson [EMAIL PROTECTED] 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. Yeah; I'm getting a little tired of having our protocols redefined based on the incorrect assumptions of people who don't understand them. The DNS sometimes uses TCP, UDP flows can last more than one round trip, and ICMP unreachable messages are an essential part of IP; vendors and operators who assume otherwise should be made to fix their assumptions, instead of everyone else having to cripple their applications and networks to make the assumptions true. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
Scott, we received similar comments during the transport directorate review of the IPFIX implementation guidelines. The new revision of the document, now available at: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt might address your concerns. I'm copying the UDP section here below for your convenience. Elisa --- 6.2. UDP UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering. However, UDP is not a reliable transport protocol, and IPFIX messages sent over UDP might be lost as with partially-reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties: o A dedicated network, o within a single administrative domain, o where SCTP is not available due to implementation constraints, o and the collector is as topographically close as possible to the exporter. Note that because UDP itself provides no congestion control mechanisms, it is recommended to use UDP transport only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. An important example of an explicitly provisioned managed network for IPFIX is use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth. As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application SHOULD NOT send UDP messages that result in IP packets that exceed the MTU of the path to the destination and SHOULD enable UDP checksums (see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines] respectively). Since IPFIX assumes reliable transport of templates over SCTP, this necessitates some changes for IPFIX template management over UDP. Templates sent from the Exporting Process to the Collecting Process over UDP MUST be resent at regular time intervals; these intervals MUST be configurable. We recommend a default Template resend time of 10 minutes, configurable between 1 minute and 1 day. Note that this could become an interoperability problem, e.g. if an Exporter re-sends Templates once per day, while a Collector expires Templates hourly, then they may both be IPFIX-compatible, but not be interoperable. Retransmission time intervals that are too short waste bandwidth on unnecessary template retransmissions. On the other hand, time intervals that are too long introduce additional costs or risk of data loss by potentially requiring the Collector to cache more data without having the Templates available to decode it. To increase reliability and limit the amount of potentially lost data the Exporting Process MAY resend additional templates using a packet- based schedule. In this case Templates are resent depending on the number of data packets sent. Similarly to the time interval, resending a Template every few packets introduces additional overhead while resending after a large amount of packets have already been sent means high costs due to the data caching and potential data loss. We recommend a default Template resend interval of 20 packets, configurable between 1 and 1000 packets. Note that a sufficiently small resend time or packet interval may cause a system to become stuck, continually re-sending templates. e.g., if the resend packet interval is 2 (i.e., templates are to be sent in every other packet) but more than two packets are required to send all the templates, then the resend interval will have expired by the time the templates have been sent, and templates will be sent continuously - possibly preventing any data from being sent at all. Therefore the Template resend intervals should be considered from the last data packet, and should not be tied to specific sequence numbers. The Collecting Process SHOULD use the Sequence Number in the IPFIX Message header to determine whether any messages are lost. The following may be done to mitigate message loss: o Move the Collector topologically closer to the Exporter. o Increase the bandwidth of the links through which the Data Records are exported. o Use sampling, filtering, or aggregation in the Metering Process to reduce the amount of exported data. o Increase the buffer size at the Collector and/or the Exporter. Before using a Template for the first time, the Exporter may send it in several different IPFIX Messages spaced out
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Fri, 28 Sep 2007, Jaap Akkerhuis wrote: There are two major reasons for an organization to not want roaming users to trust locally-assigned DNS servers. Open recursive servers doesn't help in against man in the middle attacks. If you want to avoid that use VPN's or (for DNS) TSIG. That's why you want your own caching resolver on your laptop. But I guess hotspots won't work as well with that. Then again, the whole captive portal by hacking up DNS packets needs to go away when DNSSEC deployment deems that interfering inappropriate. Is there some IETF work going on to standarize captive portal bootstraps? Paul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] security review of draft-edwards-urn-smpte-02
Hello, I have re-reviewed this document (draft-edwards-urn-smpte-02) 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 editor should treat these comments just like any other last call comments. Note: this is a revisit of the document as the first security review has been conducted on version-01 on May 8th, 2007 with no major findings but 5 comments. I still agree with the author that this document introduces no security issues other than those normally associated with the use and resolution of URNs in general. All comments from the former security review have been resolved. No new problems have been introduced. Which leaves two minor comments on version-02: 1. minor editorial comment: Section 8 references: Society of Motion Picture and Television Engineers, Uniform Resource Names for SMPTE Resources, SMPTE 2029, http://www.smpte.org (to be published). Should be changed to Society of Motion Picture and Television Engineers, Uniform Resource Names for SMPTE Resources, SMPTE 2029-2007 http://www.smpte.org As the SMPTE-2029-2007 document has been actually published (as had been required for the draft to proceed). Now just the reference text needs to be updated. 2. and the personal comment/note from the version-01 remains as I did not receive feedback on this one: a) I am not sure that SMPTE really needs a formal URN, and why an informal URN would not be sufficient. But this should be decided by the community. Note: draft version-02 introduced some justification about the need for this new namespace in section 5 of the draft. But from my personal view this mainly equals to we need our(SMPTE) own URN which is exclusively under our(SMPTE) control. As a reason this may not be considered a real reason/value by itself and thus may not be sufficient. b) As the organization seems mainly focussed on the North American Continent, it might also be a good idea to pursue via independent expert reviews the question whether there exist potential namespace conflicts with other international organizations in this area (Motion Picture and Television) like e.g. ARIB (Association of Radio Industries and Businesses) or others. Best regards, Tobias Gondrom __ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:[EMAIL PROTECTED] Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler ___ 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
On Fri, 28 Sep 2007, Dean Anderson wrote: Maybe its not mentioned because its not a practical solution. But whatever the reason it isn't mentioned, a 25 million user VPN is not going to happen with 10/8. A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) Paul ___ 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
On Fri, 28 Sep 2007, Joe Abley wrote: I'm surprised by that comment. I think it's a common use case that organisations who deploy VPNs have split DNS; that is, namespaces available through internal network resolvers that do not appear in the global namespace. In my experience, it is normal for: - VPN client software to use IP addresses rather than names to establish a secure tunnel with the home network If you are a worldwide organisation, you want to connect to the nearest VPN point, and not your home vpn point. This is done by customising DNS answers (eg bind views or akamai like setups). The last thing I want is for my Dutch branch, to connect me to the company vpn in The Netherlands, when I'm in the US, crossing the atlantic twice. You only start to use the internal company's DNS server, after you have connected to the VPN - if only to resolve internal network only machines. Paul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
It actually IS English, try installing, it localizes. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 3 Oct 2007, Marc Manthey wrote: On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ipv420.html hi Ruri , well, i could imagine what its good for , but an english version would be appreciated ;) cheers Marc -- Marc Manthey - LET - research + deployment D- 50672 Cologne Hildeboldplatz 1a web: http://www.let.de my xing profile https://www.xing.com/profile/Marc_Manthey phone mobile: 0049.221.355.80.32 0049.177.341.54.81 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 to IPv6 transition
If IANA had any resolve there are at least 25 -30 Class A blocks that should be reclaimed and are not or should not be part of the public Internet address space. At 6:56 -0400 2007/10/03, Ray Plzak wrote: Brian, My comment was regarding a head in the sand approach when it comes to the recurring themes that the developing world can't IP address space, whether it is v4 or v6. The fact is that they can get it from the RIR like those in the developed regions can get it from their RIRs. The real problem, in other words, putting head in sand, is to substitute this address space access issue for the real one of what can the recipients of the address space do with it when they get, particularly if they have no hardware to run it on, no electricity to power it, and no upstream willing to route it. It is those issues that need to be hit head on if the Internet is to really grow in the developing regions of the globe. Ray -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 4:39 PM To: Ray Plzak Cc: Tim Chown; ietf@ietf.org Subject: 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 ___ 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
On Fri, Sep 28, 2007 at 05:29:43PM -0400, Paul Wouters wrote: On Fri, 28 Sep 2007, Dean Anderson wrote: Maybe its not mentioned because its not a practical solution. But whatever the reason it isn't mentioned, a 25 million user VPN is not going to happen with 10/8. A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) http://www.6journal.org/archive/0265/ -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
On Oct 3, 2007, at 12:55 PM, Ruri Hiromi wrote: http://www.apple.com/jp/downloads/dashboard/networking_security/ ipv420.html well, i could imagine what its good for , but an english version would be appreciated ;) the widget itself is bilingual (english/japanese). itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
--On 2. oktober 2007 18:49 -0400 Russ Housley [EMAIL PROTECTED] 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? get a documented case (copy of the confirmation email + copy of the spam that got through) before jumping to conclusions. I don't think clearing the list is reasonable without relatively solid evidence that there are 200 spammers' addresses in that list. Interestingly, a confirmation email, with trace headers, is evidence of the location of a spammer that is far more solid than most kinds of evidence one can gather from just the spam; after all, the spammer was available at his MX to get and reply to the confirmation email. If the spammers were indeed auto-replying, I'd set up a honeypot running TMDA so that I could collect their whereabouts Harald ___ 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: [EMAIL PROTECTED] 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. ... 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 [destination] 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. However, if you go that way, then you lose the ability for A to assertions about which q's are not acceptable. If you add that back in as a policy knob ... We have the technology to deal with orders of magnitude more data, assuming that the task is delegated to servers, not to routers. I guess I wasn't explicit enough; I made a reference to straightforward (albeit complex and expensive) security on routing, referring to automatic mechanisms, but didn't specifically describe them as automatic; nor did I specifically refer to the policy knob as being something that was manual. I'm talking about *configuration* data; i.e. something humans have to enter, and maintain. The issue is not the mechanical tasks of storing and distributing the data, but the human effort required to set up it and update it as needed, plus the likelihood (as always, when people are involved) of errors being introduced. Noel PS: The potential size of the problem is actually worse than I described above, because there's an additional axis of freedom. Not only do you have to multiply the number of destinations by the number of backbone transits, you also have to multiply by the number of destinations *again*, because destination A may think backbone transit q is fine, with respect to communicating with B, but not when it's communicating with C. Fundamentally, destination-vector systems (of which path-vector, such as BGP, are a subset) are just not suited to doing this kind of stuff. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
Stephane == Stephane Bortzmeyer [EMAIL PROTECTED] writes: Stephane But suggesting ORNS (Open Recursive Name Servers) for Stephane the solution to this issue is, indeed, a bad idea (do Stephane note I did not say the N word), for the reasons Stephane explained in draft-ietf-dnsop-reflectors-are-evil-04.txt Stephane (reflections attack). Hmm. All I get is that suggesting open recursive nameservers has the harm that it creates reflection attacks. The current text of section 4 to me says that you SHOULD NOT offer recursive name service by default and the generic recommendation is that you should not offer recursive name service to other clients than those you need. However if I've evaluated the harm caused by the attack, evaluated the costs of other solutions and concluded that the best tradeoff is running an open recursive nameserver, I can do so. That seems like a balanced and reasonable approach. If you intend the draft to same something else, you have some work to do. Stephane There are other solutions to this issue and lists have Stephane already been given in this thread *and* in the I-D we Stephane discuss. These solutions are TSIG, local caching Stephane resolvers and VPN. May be there is an editorial problem Stephane if they are not well explained but the I-D does Stephane completely cover the issue of romaing users. People have explained why the cost/benefit tradeoff may not favor these solutions. tsig is not realistic in the current software implementation space; it has promise for the future. VPN is very complicated and probably not worth it if all you want is more reliable nameservice. (I do understand the man-in-the-middle and transparent proxy issues). Caching resolvers are problematic for deployment complexity reasons . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
Brian E Carpenter wrote: 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. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike ___ 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
Danny McPherson writes: Really? How many ISPs are you aware of that have *decommissioned* every piece of routing gear in their network in the past 7 years? I think we're an ISP (AS559), and we don't have any equipment that would be unable to filter against spoofed source addresses. In fact I think that even seven years ago all our equipment could do this. Yes, I know about certain Engine-N generations of certain linecards for certain high-end routers, but my sympathy to those ISPs who still use them is limited. (Especially with those ISPs that keep a few in their network just as an excuse for not deploying BCP39 anywhere :-) -- Simon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
I don't see a problem if we eat our own dog food. The use of tdma type tech for mailing list subscriptions has been considered best practice for over a decade. Personal use is nasty, brutish and hopefully short. Allowing unsubscribed persons to post after a tdma authentication is a courtesy, there is no obligation to extend it in the first place. Pooling the tdma responses across multiple ietf mailing lists is a further courtesy. There is more we can do here but no more that we should feel obliged to do - ecept for the fact that we are a standards organization and should eat the dog food. In particular, sign the messages with dkim and deploy spf. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time To: Brian E Carpenter Cc: ietf@ietf.org Subject:Re: Spammers answering TMDA Queries Brian E Carpenter wrote: 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. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike ___ 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
I believe the term is tmda, not tdma. TDMA is a type of cell phone technology. On 10/3/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I don't see a problem if we eat our own dog food. The use of tdma type tech for mailing list subscriptions has been considered best practice for over a decade. Personal use is nasty, brutish and hopefully short. Allowing unsubscribed persons to post after a tdma authentication is a courtesy, there is no obligation to extend it in the first place. Pooling the tdma responses across multiple ietf mailing lists is a further courtesy. There is more we can do here but no more that we should feel obliged to do - ecept for the fact that we are a standards organization and should eat the dog food. In particular, sign the messages with dkim and deploy spf. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 03, 2007 08:23 AM Pacific Standard Time To: Brian E Carpenter Cc: ietf@ietf.org Subject:Re: Spammers answering TMDA Queries Brian E Carpenter wrote: 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. Except... the annual confirmation is probably going to get accidentally deleted by a lot of people because they think it's the monthly notice. If this is a real problem, wouldn't it be better to take it up with the mailman folks since I'd expect that it's not just ietf? I've been working with them on dkim related stuff and they are quite reasonable folks. Maybe they have some ideas on this front. Mike ___ 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 -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers answering TMDA Queries
On Oct 3, 2007, at 2:59 PM, Hallam-Baker, Phillip wrote: There is more we can do here but no more that we should feel obliged to do - except for the fact that we are a standards organization and should eat the dog food. In particular, sign the messages with dkim and deploy spf. Few problems should be caused by DKIM, although it might be difficult to claim DKIM solves a particular problem affecting IETF mailing lists. The same is not true for SPF. SPF is experimental, can be problematic, and is very likely unsafe for use with DNS. SPF carries suitable warnings indicating it may cause problems. SPF may interfere with the delivery of forwarded messages. SPF might be used in conjunction with Sender-ID. Suggested solutions for dealing with Sender-ID requires yet another version of SPF be published. Use of which might fall under: http://www.microsoft.com/downloads/results.aspx? pocId=freetext=SenderID_License-Agreement.pdfDisplayLang=en Possible application of Sender-ID will cause IETF lists to break once SPF is published. The purported use of SPF for curtailing forged DSNs requires policy settings which then create new problems. When desired, names rather than address lists should be used to register an email path. A name path approach avoids the dangerous DNS transactional issues. Rather than relying upon unscalable SPF address lists, instead an extension might be applied to DKIM. The DKIM extension could offer a means to prevent DSNs from being dropped when Mail From domains differ. http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has approved the following document: - 'Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) ' draft-ietf-rohc-sigcomp-sip-08.txt as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-08.txt Technical Summary This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. Working Group Summary This document has been in the workings for several years, and it has been given the time needed to make it mature. The document has been carefully reviewed by both the WG and various other SIP and SigComp experts, and there is WG consensus that the document should now be published as an RFC. Document Quality There are several independent implementers of SigComp, and they have collectively developed the content of this specification, based on running code experience. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
