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
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: [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: [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: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://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 Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Sorry, I said support, I meant use. Any numbers there? -danny ___ 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 Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Sorry, I said support, I meant use. Any numbers there? -danny I use TSIG on my laptop. As for others I have no idea. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://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
It does indeed as Stephane pointed out. Opening up your resolver so you can server roaming users, without further protection, is, at best, naive. Joao On 28 Sep 2007, at 12:15, 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. I seem to remember that the ID actually mentions that. jaap ___ DNSOP mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dnsop ___ 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 28-Sep-2007, at 1136, Paul Hoffman wrote: It is not obvious, at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. 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 - Local resolver settings on the VPN client's machine to be re- written to use internal home network nameservers while the VPN session is active This is certainly how the cisco VPN client supplied to me by my employer (and the subsequent versions I've downloaded directly from cisco) work, for example. I was under the impression that cisco had fairly significant market share in this area. This is not to say that the topic doesn't deserve mention in the draft at hand. However, your logic in the last sentence above seems suspect to me. Joe ___ 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
At 12:04 PM -0400 9/28/07, Joe Abley wrote: On 28-Sep-2007, at 1136, Paul Hoffman wrote: It is not obvious, at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. 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 - Local resolver settings on the VPN client's machine to be re-written to use internal home network nameservers while the VPN session is active That's completely true for remote users who are already using a VPN. In that case, there is no reason for the organization to have a recursive resolver facing outwards. What was being discussed was setting up a VPN just for getting DNS resolution, not for access to other internal resources. IPsec can be used to create a tunnel to just a single resource if the organization wants the external user to access that resource only. --Paul Hoffman, Director --VPN Consortium ___ 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 28-Sep-2007, at 1136, Paul Hoffman wrote: It is not obvious, at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. I'm surprised by that comment. I'm not. As it happens I've used three different VPN services in the past few years and I will soon be forced to switch to a fourth. In each case the IT folks managed to jury-rig things so that DNS queries got redirected, but I've been told in some cases it required quite a bit of effort. And it is also my understanding that requiring this significantly limited our our options in choosing VPN solutions. 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. Yes, we have this in spades at Sun. Can't say it works all that well, but this is really a separate issue. 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 I'm sure this is done, but I think it is more common to use DNS entries. You have to validate the server's certificate or whatever anyway, so all direct use of IP address does is limit certain denial of service attacks but at the cost of a significant loss in flexibility. - Local resolver settings on the VPN client's machine to be re- written to use internal home network nameservers while the VPN session is active Yeah, that's what the client ends up doing. I don't know the specifics of how this has been implemented in the various clients I've had to use, but it has tended to be quite fragile - on numerous occasions things have failed in such a way that my DNS settings were completely trashed and I had to go in and reset them manually. I eventually wrote a little script I can run to force things back to where they're supposed to be with a single command. Perhaps if this the need for this were called out more specifically more attention would be paid to making this work well. This is certainly how the cisco VPN client supplied to me by my employer (and the subsequent versions I've downloaded directly from cisco) work, for example. I was under the impression that cisco had fairly significant market share in this area. Since I don't really know who or what's responsible for the many problems I've seen with this I'm not going to provide specifics regarding the clients I've used. However, I will say that I think you've had a fair bit of luck here. This is not to say that the topic doesn't deserve mention in the draft at hand. However, your logic in the last sentence above seems suspect to me. FWIW, I am in full support of Paul and John's position here. Ned ___ 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 28-Sep-2007, at 1516, Dean Anderson wrote: Not widely supported in clients. Therefore, not a solution. In fact, it's quite feasible in operating systems which can run a local instance of (say) BIND9. It would be fair to say that installing and configuring BIND9 on an average laptop is far beyond the abilities of the average laptop owner, but that's presumably just a matter of packaging. VPN are another solution, although not mentioned in the I-D, may be because it is obvious. 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. Well, that depends on what you mean by VPN. If you mean a hub and spoke topology of tunnels, all concentrated centrally then yeah, that sounds like a bit of a stretch. If you mean use of AH in queries sent towards a resolver which is configured somehow to discard packets that are not authentic then I suspect there are ways to make that scale, even for quite large client populations. (I might choose to incorporate anycast into such a design. You, presumably, would not. :-) A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. I have heard such reports from Comcast in various forums. I have no reason to doubt them. I do not think that is especially pertinent to the question at hand, however. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
