Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Jeroen Massar wrote: Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. The biggest issue with reverse mapping for clients (any protocol) is that people try to make their applications treat it as anything but here is some information you might find interesting. I think draft-ietf-dnsop-reverse-mapping-considerations-05.txt has it right: 4.3 Application considerations Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not work in its absence. Operators and users are reminded that the use of the reverse tree, sometimes in conjunction with a lookup of the name resulting from the PTR record, provides no real security, can lead to erroneous results and generally just increases load on DNS servers. FYI, I ssh out from the address I used as an example above every day. Thinking that SSH clients should be required to be on round-trippable mapped addresses is just silly. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
On 21 feb 2008, at 14:31, Rémi Després wrote: - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). You're right, there is currently no way other than a rather non- obvious use of manual address configuration or DHCPv6 address pool configuration to arrive at an interface identifier where the U/L bit is global and the group bit is set, i.e., with bits 6 and 7 of the IID set to 1. This means that there is an untapped range of 62 bits worth of IIDs that we can still give a new purpose where the address type can be relatively unambiguously determined from the IID. It would be a shame to squander that resource without thinking about other uses first. (Although using only one of the 64 possible ranges of 56 bits is probably reasonalbe.) But shouldn't we be having this discussion in 6man? ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: Harald Alvestrand a écrit : Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a generic privacy address. - This address would be the /64 of the link followed by an agreed joker IID (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this generic privacy address of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for dsitinguishable privacy addresses. - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. My desire to have privacy is, in itself, something I may want to keep private. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
This is a retransmission with a source address accepted on this discussion list. Apologies to those who received it already. If you respond, please use preferably this copy. RD Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a "mechanism" is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a "generic privacy address". - This address would be the /64 of the link followed by an agreed "joker IID" (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this "generic privacy address" of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for "dsitinguishable privacy addresses". - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. RD ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand a écrit : Rémi Després wrote: Harald Alvestrand a écrit : Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a generic privacy address. - This address would be the /64 of the link followed by an agreed joker IID (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this generic privacy address of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for dsitinguishable privacy addresses. - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. RD ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Iljitsch van Beijnum a écrit : On 21 feb 2008, at 14:31, Rémi Després wrote: - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). (Sorry for the typo. Should be 56.) You're right, there is currently no way other than a rather non-obvious use of manual address configuration or DHCPv6 address pool configuration to arrive at an interface identifier where the U/L bit is global and the group bit is set, i.e., with bits 6 and 7 of the IID set to 1. This means that there is an untapped range of 62 bits worth of IIDs that we can still give a new purpose where the address type can be relatively unambiguously determined from the IID. It would be a shame to squander that resource without thinking about other uses first. (Although using only one of the 64 possible ranges of 56 bits is probably reasonalbe.) But shouldn't we be having this discussion in 6man? Yes, I think so. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? You're not thinking this through. Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a while (although their behaviour still surprises many). Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
On 21 feb 2008, at 16:34, Harald Alvestrand wrote: Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. I'm assuming you mean a trace of the activities of addresses from that LAN as seen from elsewhere, because if they can sniff the LAN they can also see the link addresses. But what the good/bad guy sees is 1099 addresses, 999 of which are used for somewhat long periods, and 100 of which are used for somewhat short periods. They don't know how many users there were on the LAN, although they can probably guess to within 10% or so based on the amount of traffic. They also don't have any way to know which user was using which privacy address at any given time unless they had a much more intimite view of the LAN in question. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Iljitsch van Beijnum wrote: On 21 feb 2008, at 16:34, Harald Alvestrand wrote: Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. I'm assuming you mean a trace of the activities of addresses from that LAN as seen from elsewhere, because if they can sniff the LAN they can also see the link addresses. But what the good/bad guy sees is 1099 addresses, 999 of which are used for somewhat long periods, and 100 of which are used for somewhat short periods. They don't know how many users there were on the LAN, although they can probably guess to within 10% or so based on the amount of traffic. They also don't have any way to know which user was using which privacy address at any given time unless they had a much more intimite view of the LAN in question. Unless you implement an identifiable format for privacy enhanced addresses; in that case they can 100% accurately say that 100 addresses were used by someone with something to hide. That was the idea I was trying to point out the bad sides of. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Harald Alvestrand wrote : Rémi Després wrote: My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? You're not thinking this through. Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. Right if the user keeps the same address for a series of outgoing connections. However things are different in the context in which I proposed, in earlier mails of the same thread, that the resolver would query the DNS for site prefixes. The concern was client hosts for which one desires both: (1) a privacy similar to that offered by NATs; (2) undisturbed E2E significance of addresses and ports. For this, the idea at hand is that these clients would use a fresh privacy address for each outgoing connection (with some more specification work left to avoid unreasonable Duplicate Address Detection). If this is done, the poor mafioso will believe that consecutive connections of a single host are connections initiated by various hosts (or at least will be unable to decide which connections come from the same host) :-). If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a while (although their behaviour still surprises many). Thanks. I will have a look. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
PTR for IPv6 clients (Re: IPv6 NAT?)
Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
