Re: [Cryptography] IPv6 and IPSEC
On Tue, Sep 3, 2013 at 8:54 PM, Lucky Green shamr...@cypherpunks.to wrote: In its cryptic explanation of the bounces, Google makes one thing clear: whatever reason they have to bounce the email, that reason only applies to IPv6. I believe this is wrong. It only applies to IPv6 because applying it to IPv4 would break too many people. Not enough people use IPv6, so they are insisting on good hygiene there. Why do you not have PTR records for your IPv6 address? The problem is that, not Google's policy. -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Sep 4, 2013 12:14 AM, Lucky Green shamr...@cypherpunks.to wrote: I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. SPF uses TXT records, not PTR ones. Can you share your IPv6 address? I'll take a look. - JP ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Tue, Sep 03, 2013 at 10:27:14PM -0700, Taral wrote: On Tue, Sep 3, 2013 at 8:54 PM, Lucky Green shamr...@cypherpunks.to wrote: In its cryptic explanation of the bounces, Google makes one thing clear: whatever reason they have to bounce the email, that reason only applies to IPv6. I believe this is wrong. It only applies to IPv6 because applying it to IPv4 would break too many people. Not enough people use IPv6, so they are insisting on good hygiene there. Why do you not have PTR records for your IPv6 address? The problem is that, not Google's policy. I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. --Lucky ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, 4 Sep 2013 09:14:36 +0200 Lucky Green shamr...@cypherpunks.to wrote: I *have* PTR records for my IPv6 addresses. What I don't know is which PTR records will make Gmail happy. SPF PTR records clearly do not do the trick. I think this conversation has, at this point, gone well beyond the scope of the list. There are a bunch of google people on the mailing list, perhaps one or more of them might want to contact Lucky in private and see if they can help him with his question. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
At 01:53 PM 8/29/2013, Taral wrote: Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. For IPv4, that's a relatively normal way to do things, though if example.com is commercial, smtp.example.com might actually be a load-balanced bunch of servers in xx.yy.zz.0/24 instead of just one machine, or they might be hidden behind NAT. But with IPv6 privacy extensions, a single machine might be using pseudorandomly-generated addresses in a /64 subnet, so you'd have to do some kind of wildcarding to represent it as a single name. Also, residential vs. commercial is a much fuzzier boundary for IPv6; an IPv6 machine might be a VM tunnelling to Hurricane Electric over IPv4, or tunnelled from a residence to a DSL ISP that can only do telco DSL at IPv4. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Tue, Sep 03, 2013 at 06:09:15PM -0700, Bill Stewart wrote: For IPv4, that's a relatively normal way to do things, though if example.com is commercial, smtp.example.com might actually be a load-balanced bunch of servers in xx.yy.zz.0/24 instead of just one machine, or they might be hidden behind NAT. But with IPv6 privacy extensions, a single machine might be using pseudorandomly-generated addresses in a /64 subnet, so you'd have to do some kind of wildcarding to represent it as a single name. Also, residential vs. commercial is a much fuzzier boundary for IPv6; an IPv6 machine might be a VM tunnelling to Hurricane Electric over IPv4, or tunnelled from a residence to a DSL ISP that can only do telco DSL at IPv4. Friends, Here is the bottom line. PHB suggested to use IPv6 as part of a local email encryption solution. I observed that as of two weeks ago, I am unable to send emails via IPv6 to Gmail addresses. Actually, it is worse than that. I am unable to send email via IPv6 to any email address hosted by Google, which are far more email addresses in my address book than emails that end in @gmail.com. In its cryptic explanation of the bounces, Google makes one thing clear: whatever reason they have to bounce the email, that reason only applies to IPv6. I believe this is wrong. Trying to determine the reason for the SMTP 5xx error, given the cryptic explanation in Google's FAQ, I /believe/ they want the forward and RDNS to match. Perhaps I misunderstood the poorly worded explanation. But this does not change the bottom line: I am no longer able to send email via IPv6 to Google SMTP servers. Not from home, where I have a tunnel via my DSL provider. Not from my server in the colo, which is in a different continent and where I have a full /48. I can't be the only one with this problem given Google's policy change a couple of weeks ago. Over 95% off my traffic used to flow over IPv6. Since the Google policy change, 0% of my SMTP traffic flows over IPv6. I had no choice but to disable IPv6 in postfix. I have no clue what would make Google happy? Matching forward and RDNS? I can't even get that for IPv4. Not at the colo, not at home. Something else? I do not know what that would be, but I am pretty sure whatever it is I cannot bring about. If nothing else comes out of this thread, if any reader happens to know somebody at Google, perhaps you can convince them to articulate clearly what DNS properties they demand for IPv6 (but not IPv4) that will cause Gmail to again accept SMTP over IPv6. The irony here is that I have been using IPv6 for years without any problems. Companies such as Google have paved the way for solid IPv6 support by large providers. Never had any problem. And now Google decides to break IPv6 with no clear explanation why or how to remedy the situation. Flat out of ideas, --Lucky ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, Aug 28, 2013 at 01:47:01PM -0400, Phill wrote: (This is the last week before school goes back which is stopping me getting to the big iron and my coding platform if folk are wondering where the code is). I had a discussion with some IETF types. Should I suggest a BOF in Vancouver? Maybe this is an IRTF effort rather than IETF. One thing that we maybe should face is IPR considerations and move what is becoming a design discussion to a list with an established IPR rubric like Note Well. In the past I have had whole standards efforts collapse because Microsoft or whoever objected to the IPR being possibly contaminated by being discussed in a forum without an IPR regime (though I suspect that was a pretext rather than a reason). One question is whether we could make use of IPSEC and/or IPv6. Now I do not for an instant accept that we should make any proposal dependent on deployment of either. However IPv6 does have some very convenient characteristics for traffic analysis hardening. My view has always been that the proper approach to security is to have multiple layers so I would see IPSEC as being an addition to TLS and message layer security. As of about 10 days ago, Gmail began rejecting incoming IPv6 SMTP traffic from IPv6 address for which the forward and reverse DNS do not match. Since forward and reverse DNS will rarely match for IP addresses used by individuals rather than service providers, this change precludes home users of IPv6 from sending email to Gmail acccount. So unless you never send email to Gmail users or control both forward and reverse DNS, IPv6 is (no longer) suitable for sending email. Note that this new restriction imposed by Gmail only applies to IPv6 addresses, not IPv4 addresses. I had to disable IPv6 in postfix to continue to be able to send to Gmail. Here is the error message: user_name_remo...@gmail.com: host gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b] said: 550-5.7.1 [2001:888:2133:0:82:94:251:205 16] Our system has detected that 550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR 550-5.7.1 records and authentication. Please review 550 5.7.1 https://support.google.com/mail/answer/81126 for more information. x13si636989wij.49 - gsmtp (in reply to end of DATA command) Google's support URL in the 550 error contains this gem: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. [The support URL then also talks about recommending SPF or DKIM, but enabling SPF does not stop the 550 errors] --Lucky, who long ago IPv6-enabled every single system under his control. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
Since forward and reverse DNS will rarely match for IP addresses used by individuals rather than service providers, this change precludes home users of IPv6 from sending email to Gmail acccount. Note that this new restriction imposed by Gmail only applies to IPv6 addresses, not IPv4 addresses. For many years now, most mail servers have been rejecting mails sent from dynamic IPs. And for IPv6 specifically, long before Gmail, a lot of ISPs already required forward and reverse DNS to match. --Mo ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Thu, Aug 29, 2013 at 4:53 PM, Taral tar...@gmail.com wrote: Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. So Lucky's problem seems to be that the ISPs providing IPv6 have decided on a convention that they identify residential IPv6 ranges by not filling in the reverse PTR info And the problem he has is that Google won't take email from a residential IPv6. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. -- Website: http://hallambaker.com/ -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] IPv6 and IPSEC
On Thu, Aug 29, 2013 at 01:53:29PM -0700, Taral wrote: Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. Right, so if you have abc.example.com and def.example2.com both pointing to IP1 and IP2, and IP1 and IP2 both point to abc.example.com, what's the problem? On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. Website: http://hallambaker.com/ Taral tar...@gmail.com slainte mhath, RGB -- Richard Guy Briggs -- ~\-- ~\hpv.tricolour.net www.TriColour.net-- \___ o \@ @ Ride yer bike! Ottawa, ON, CANADA -- Lo___M__\\/\%__\\/\% Vote! -- greenparty.ca_GTVS6#790__(*)__(*)(*)(*)_ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] IPv6 and IPSEC
(This is the last week before school goes back which is stopping me getting to the big iron and my coding platform if folk are wondering where the code is). I had a discussion with some IETF types. Should I suggest a BOF in Vancouver? Maybe this is an IRTF effort rather than IETF. One thing that we maybe should face is IPR considerations and move what is becoming a design discussion to a list with an established IPR rubric like Note Well. In the past I have had whole standards efforts collapse because Microsoft or whoever objected to the IPR being possibly contaminated by being discussed in a forum without an IPR regime (though I suspect that was a pretext rather than a reason). One question is whether we could make use of IPSEC and/or IPv6. Now I do not for an instant accept that we should make any proposal dependent on deployment of either. However IPv6 does have some very convenient characteristics for traffic analysis hardening. My view has always been that the proper approach to security is to have multiple layers so I would see IPSEC as being an addition to TLS and message layer security. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
