Glen, IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-02>for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks, Glen
Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only. AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet). Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it. Be happy to answer any more questions offline. - merike On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks, Glen
Not really. Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted. A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted. So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc. A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best. I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH. Jack On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <kaeo@merike.com> wrote:
Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination
authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks, Glen
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the "wesp" proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin. Any reasons why we still see it around? Thanks, Glen On Tue, May 26, 2009 at 5:44 AM, Jack Kohn <kohn.jack@gmail.com> wrote:
Not really.
Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted.
A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted.
So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc.
A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best.
I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH.
Jack
On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <kaeo@merike.com> wrote:
Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination
authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks, Glen
Coming from someone who is somewhat jaded.....politics. Realistically there are some folks who believe that not having the IP header (and with v6 also the option headers) integrity protected is an issue. It's not. You have more risk of operation issues from adding complexity of AH.....note that the fields that are modified in transit in the headers are NOT included in the integrity protection. So it really becomes an issue of is the IP address protected and basically, yes that's done via IKE and the way security associations work anyhow. [if you change IP address of header you will not have appropriate security association match] Once the technology is there to quickly differentiate ESP-Null from ESP-encrypted packets the argument of "but you can inspect AH packets" becomes irrelevant. - merike On May 25, 2009, at 5:23 PM, Glen Kent wrote:
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the "wesp" proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin.
Any reasons why we still see it around?
Thanks, Glen
On Tue, May 26, 2009 at 5:44 AM, Jack Kohn <kohn.jack@gmail.com> wrote:
Not really.
Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted.
A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted.
So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc.
A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best.
I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH.
Jack
On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <kaeo@merike.com> wrote:
Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme- charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/ html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
> Hi, > > It is well known in the community that AH is NAT unfriendly > while ESP > cannot > be filtered, and most firewalls would not let such packets > pass. I am > NOT >
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination > authentication > (Integrity Protection). Do folks in such cases use AH or ESP- > NULL, > given
that both have some issues?
> > Thanks, > Glen > >
Hmm .. besides this, AH is *never* export restricted. Also, i could be mistaken, but isnt AH compliance mandatory in IPv6? Earlier there were some issues in using ESP with TCP performance enhancement proxies used in wireless networks, which couldnt deep inspect the ESP packets to extract TCP flow IDs and seq numbers, but that should all change with the new WESP proposal. Jack On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo <kaeo@merike.com> wrote:
Coming from someone who is somewhat jaded.....politics.
Realistically there are some folks who believe that not having the IP header (and with v6 also the option headers) integrity protected is an issue. It's not. You have more risk of operation issues from adding complexity of AH.....note that the fields that are modified in transit in the headers are NOT included in the integrity protection. So it really becomes an issue of is the IP address protected and basically, yes that's done via IKE and the way security associations work anyhow. [if you change IP address of header you will not have appropriate security association match]
Once the technology is there to quickly differentiate ESP-Null from ESP-encrypted packets the argument of "but you can inspect AH packets" becomes irrelevant.
- merike
On May 25, 2009, at 5:23 PM, Glen Kent wrote:
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH
now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the "wesp" proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin.
Any reasons why we still see it around?
Thanks, Glen
On Tue, May 26, 2009 at 5:44 AM, Jack Kohn <kohn.jack@gmail.com> wrote:
Not really.
Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted.
A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted.
So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc.
A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best.
I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH.
Jack
On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <kaeo@merike.com> wrote:
Yeah - the main issue with using ESP is that there's a trailer at end of
packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> > wrote: > > Hi, >> >> It is well known in the community that AH is NAT unfriendly while >> ESP >> cannot >> be filtered, and most firewalls would not let such packets pass. I >> am >> NOT >> >> > 'the content of the esp packet can't be filtered in transit' I think > you mean... right? > > interested in encrypting the data, but i do want origination > >> authentication >> (Integrity Protection). Do folks in such cases use AH or ESP-NULL, >> >> given >
that both have some issues?
> >> Thanks, >> Glen >> >> >>
IPsec as a whole is compliance mandatory for IPv6 although for new version of IPv6 Node requirements that came out recently I think they changed that to a 'SHOULD'. Wireless devices (phones) have issues with battery life when IPsec implemented. Note that all standards say ESP-Null is 'MUST' (mandatory-to-implement ) algorithm and AH is a 'MAY' support. Yep.....integrity was specifically decoupled due to export restrictions on cryptography technologies used for encryption - the restrictions do not apply for just authentication/integrity cryptography. Hence AH and ESP. ESP-Null came about when folks realized AH could not traverse NATs. - merike On May 25, 2009, at 8:26 PM, Jack Kohn wrote:
Hmm .. besides this, AH is *never* export restricted. Also, i could be mistaken, but isnt AH compliance mandatory in IPv6?
Earlier there were some issues in using ESP with TCP performance enhancement proxies used in wireless networks, which couldnt deep inspect the ESP packets to extract TCP flow IDs and seq numbers, but that should all change with the new WESP proposal.
Jack
On Tue, May 26, 2009 at 8:21 AM, Merike Kaeo <kaeo@merike.com> wrote: Coming from someone who is somewhat jaded.....politics.
Realistically there are some folks who believe that not having the IP header (and with v6 also the option headers) integrity protected is an issue. It's not. You have more risk of operation issues from adding complexity of AH.....note that the fields that are modified in transit in the headers are NOT included in the integrity protection. So it really becomes an issue of is the IP address protected and basically, yes that's done via IKE and the way security associations work anyhow. [if you change IP address of header you will not have appropriate security association match]
Once the technology is there to quickly differentiate ESP-Null from ESP-encrypted packets the argument of "but you can inspect AH packets" becomes irrelevant.
- merike
On May 25, 2009, at 5:23 PM, Glen Kent wrote:
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the "wesp" proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin.
Any reasons why we still see it around?
Thanks, Glen
On Tue, May 26, 2009 at 5:44 AM, Jack Kohn <kohn.jack@gmail.com> wrote: Not really.
Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted.
A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted.
So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc.
A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best.
I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH.
Jack
On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo <kaeo@merike.com> wrote:
Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only.
AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet).
Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it.
Be happy to answer any more questions offline.
- merike
On May 25, 2009, at 6:24 AM, Jack Kohn wrote:
Glen,
IPSECME WG <http://www.ietf.org/html.charters/ipsecme-charter.html> at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets).
You can look at draft-ietf-ipsecme-traffic-visibility-02<http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02>for more details.
Jack
On Sat, May 23, 2009 at 5:06 AM, Glen Kent <glen.kent@gmail.com> wrote:
Yes, thats what i had meant !
On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Fri, May 22, 2009 at 1:04 PM, Glen Kent <glen.kent@gmail.com> wrote:
Hi,
It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT
'the content of the esp packet can't be filtered in transit' I think you mean... right?
interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL,
given
that both have some issues?
Thanks, Glen
Merike Kaeo wrote: ...
ESP-Null came about when folks realized AH could not traverse NATs.
Thus the absolute reason why people should promote AH to kill off the 66nat nonsense. Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset. Tony
On May 27, 2009, at 3:00 AM, Tony Hain wrote:
Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset.
I concur quite strongly with your views on this particular topic, but the CGN boat appears to've sailed, AFAICT. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Unfortunately, inefficiency scales really well. -- Kevin Lawton
On 27/05/2009, at 8:11 AM, Roland Dobbins wrote:
On May 27, 2009, at 3:00 AM, Tony Hain wrote:
Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset.
I concur quite strongly with your views on this particular topic, but the CGN boat appears to've sailed, AFAICT.
Note that Tony is talking about 6-to-6 NAT, not 6-to-4 NAT or vice versa (not to be confused with 6to4 tunnelling). I'm not sure that boat has sailed yet. -- Nathan Ward
Tony Hain wrote:
Merike Kaeo wrote: ...
ESP-Null came about when folks realized AH could not traverse NATs.
Thus the absolute reason why people should promote AH to kill off the 66nat nonsense. Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset.
That should make for a fascinating discussion. "You should use AH." "Why?" "So you can't use NAT." "Any other reason?" "... No." "Great. I'll get right on that." The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing. BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick. -Dave
The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing.
BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick.
I agree. Folks are going to use ESP-NULL if they really want Integrity Protection ..
-Dave
I agree as well that ESP-Null the way to go for integrity. From operational perspective if you are supporting both v4 and v6 (and you will) then having different protocols will be a nightmare. Common denominator is ESP-Null. Realistically for IPsec, unless you have the scalable credential issue resolved and easier configs from vendors, the operational time sync will have many looking elsewhere to accomplish what's needed in the name of security. (total bummer IMHO). - merike On May 26, 2009, at 4:35 PM, Jack Kohn wrote:
The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing.
BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick.
I agree. Folks are going to use ESP-NULL if they really want Integrity Protection ..
-Dave
participants (8)
-
Dave Israel -
Glen Kent -
Jack Kohn -
Merike Kaeo -
Nathan Ward -
Randy Bush -
Roland Dobbins -
Tony Hain