Re: [IPsec] draft-bhatia-moving-ah-to-historic
On 16/04/2012 12:25, Yoav Nir wrote: > It only adds confusion and complication in the sense that telnet adds > them (ESP is SSH in this analogy). To be fair, it adds a lot more confusion than telnet vs ssh. With my !inex.ie hats on, I see smart but untrained ops people attempting to configure up their firewall / vpn systems and not realise that AH is actually a separate protocol, but actually requires end-to-end support for protocol 51. Then they stumble on the fact that it doesn't work with NAT and further anxiety ensues. Debugging firewall problems is at least a level 2 support issue, and often requires escalation to level 3. This sort of support burden is expensive. > If you don't implement it you and your users don't get confused. It's not me using it - it's my clients' customers. The end-users are one level further removed from that. > Besides, the end users of IPsec who actually have to know what ESP is vs > what AH is are very sophisticated. They're not the people who simply > press "Connect" on their L2TP or VPN clients. Indeed, and I'm talking about operators who configure these services, not end users who click connect. > Maybe, maybe not. As ISPs move large blocks of users to a combination of > IPv6 and CGN, blocks of IPv4 address space may be freed up. But > regardless, NAT *is* going to be with us for a while, even in IPv6. I question whether we will ever transition to ipv6. I hope we will, but rate it somewhat unlikely at this stage of the Internet's evolution. This is a separate discussion though. IPv4 NAT will be around for the forseeable future - e.g. many decades at the very least. > Nothing's stopping you from proposing 4302bis, which will be compatible > with NATs. There just isn't much demand for changing AH like that. That particular wheel has already been invented many times at many layers (esp, ssl/tls, etc). > Suppose the TICTOC working group decide that they need packet > authentication for time signals, but not encryption. (makes sense, as > they only deliver the time of day). They can go with either AH or > ESP-Null. They also don't care about NAT, because NATs introduce so much > jitter, that they'll ruin the accuracy of PTP, so PTP does not go > through NAT anyway. They also first construct the IPsec packet, then > paste the timestamp where it's needed, and quickly calculate the hash. > If they can do this with less jitter with AH than with ESP, do you think > they'll actually care whether they're using a "current" or "historic" > standard? They'll just use whatever gets the job done better. This is an edge case. It's possible to create edge cases for anything. > Even "historic" does not mean everyone has to stop using it, even in new > standards. It just means that you have to have a really good > justification why you need that rather than ESP. That's the situation > already. Declaring it so doesn't help. The IETF is very self-deprecating about historic status. There's nothing wrong with a document saying: -- operators: this protocol has serious problems in practice. therefore we suggest you use $otherprotocol which has none of these problems and is better in almost every other respect. developers: don't bother. no point. -- Call it good housekeeping. Call it operational guidance that access providers can show to their customers about why AH is not a good idea. Whatever it's called, historic status is a good place for moribund protocols to be placed, lovingly or otherwise. > Well, this draft generated a 77-post thread. Then the mailing list got > quiet about it, and we had three months without any mention of AH. Sounds pretty typical for most mailing lists...? > I think moving it to historic creates a lot more mailing list chatter > than ignoring it. Right now yes. But this argument will go round in circles for the next 50 years until people finally accept that AH is generally not useful. During that time, there will be much mailing list chatter about it, on this and other lists. Best consign it to history and close that particular door. It was good while it was relevant, but those times are gone. Nick ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-bhatia-moving-ah-to-historic
On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote: > I'd like to add a voice of support to this draft. AH adds little except > complication to ipsec implementations and confusion to end users. It only adds confusion and complication in the sense that telnet adds them (ESP is SSH in this analogy). If you don't implement it you and your users don't get confused. Besides, the end users of IPsec who actually have to know what ESP is vs what AH is are very sophisticated. They're not the people who simply press "Connect" on their L2TP or VPN clients. > Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4 > scarcity is realised worldwide (particularly in asia, which is currently > the fastest growing global region, and has already reached RIR exhaustion). Maybe, maybe not. As ISPs move large blocks of users to a combination of IPv6 and CGN, blocks of IPv4 address space may be freed up. But regardless, NAT *is* going to be with us for a while, even in IPv6. > There was a previous comment about this draft about the NAT/AH issue being > a NAT problem rather than an AH problem. Well, yeah, in the purest sense > this is true, but we live in the real world and need to work within its > limitations. You can apply fixups and ALGs to lots of protocols which are > NAT sensitive, but AH is cryptographically incompatible with NAT and this > cannot be fixed. Nothing's stopping you from proposing 4302bis, which will be compatible with NATs. There just isn't much demand for changing AH like that. > I see little value in the IETF formally supporting a protocol which simply > cannot work for most end-users on the basis of the access addressing > provided. Formal deprecation / designation to historic status is > appropriate in this case. Formal deprecation is pretty much meaningless. Consider this example: Suppose the TICTOC working group decide that they need packet authentication for time signals, but not encryption. (makes sense, as they only deliver the time of day). They can go with either AH or ESP-Null. They also don't care about NAT, because NATs introduce so much jitter, that they'll ruin the accuracy of PTP, so PTP does not go through NAT anyway. They also first construct the IPsec packet, then paste the timestamp where it's needed, and quickly calculate the hash. If they can do this with less jitter with AH than with ESP, do you think they'll actually care whether they're using a "current" or "historic" standard? They'll just use whatever gets the job done better. Even "historic" does not mean everyone has to stop using it, even in new standards. It just means that you have to have a really good justification why you need that rather than ESP. That's the situation already. Declaring it so doesn't help. > Also +1 to the following arguments: > > - ESP + NULL == substantially equivalent > - less mailing list chatter Well, this draft generated a 77-post thread. Then the mailing list got quiet about it, and we had three months without any mention of AH. I think moving it to historic creates a lot more mailing list chatter than ignoring it. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] draft-bhatia-moving-ah-to-historic
I'd like to add a voice of support to this draft. AH adds little except complication to ipsec implementations and confusion to end users. Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4 scarcity is realised worldwide (particularly in asia, which is currently the fastest growing global region, and has already reached RIR exhaustion). There was a previous comment about this draft about the NAT/AH issue being a NAT problem rather than an AH problem. Well, yeah, in the purest sense this is true, but we live in the real world and need to work within its limitations. You can apply fixups and ALGs to lots of protocols which are NAT sensitive, but AH is cryptographically incompatible with NAT and this cannot be fixed. I see little value in the IETF formally supporting a protocol which simply cannot work for most end-users on the basis of the access addressing provided. Formal deprecation / designation to historic status is appropriate in this case. Also +1 to the following arguments: - ESP + NULL == substantially equivalent - less mailing list chatter Nick ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
