Re: [IPsec] P2P VPN - Side Meeting
On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We will have plenty of opportunity to discuss these things at the meeting on Wednesday, but just to make things clear, I am not advocating any solution, and I have no unsubmitted draft with some extension to IKE. The purpose of the meeting is to review the use cases and the solutions that currently exist. If anyone intends to pull out a new never-before-published solution that's fine as well, but I have no such intentions. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Does ESP provide all functionality offered by AH?
At 1:56 AM -0500 11/15/11, Steven Bellovin wrote: On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote: De... The notion of discarding AH entirely has been discussed for many years. I've long been in favor of it, though I can't find a copy of anything old I had posted in my mail archives at the moment. The counter-argument -- and again, it's been presented many times over many years -- is that AH protects some IP options. That's useless in IPv4; the assertion is that it's important in IPv6. 4301 deprecates AH, by making support for it a MAY, vs. a MUST for ESP, as part of a compliant IPsec implementation. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Hi Yoav, Please see inline. Mike. On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We use other tunnel mechanisms (GRE), because IPsec tunneling mode is lacking in functionality. For example, when you use GRE for the tunneling you also reduce the IPsec SA's that are needed to describe the traffic for IPsec to encrypt. If you use IPsec tunnel mode only then for each pairing of subnets behind each peer you need a separate IPsec SA. For example if there are 5 subnets each behind two peers then you need up to 25 SA pairs to describe exactly what needs to be encrypted and nothing more. If you tunnel the data traffic first then you only need 1 SA pair for all traffic, since IPsec encrypts the tunnel itself and not the traffic within the tunnel. What you call other fancy features is what I call functional separation. IPsec does encryption well, but in reality it does a fairly poor job of tunneling. So lets have IPsec do what it does well and have GRE do what it does well and that is tunneling. Then you add NHRP do to next-hop resolution, which is what it was specifically designed to do, so that you can dynamically find peers and dynamically build new GRE tunnels protected by IPsec. Note, NHRP runs through the GRE tunnel so the single IPsec SA, since it encrypts the tunnel, also protects NHRP. Finally you add a routing protocol to advertise the reachablity of subnets/networks through the tunnel. Again this all goes through tunnel so the single IPsec SA protects this traffic as well. Basically you now have a system where you are using the proper tool to do the job that it was designed to do and that it does best. If you were to to try to overload these functions back into IPsec/IKE then you would end up with a less efficient system. We will have plenty of opportunity to discuss these things at the meeting on Wednesday, but just to make things clear, I am not advocating any solution, and I have no unsubmitted draft with some extension to IKE. The purpose of the meeting is to review the use cases and the solutions that currently exist. If anyone intends to pull out a new never-before-published solution that's fine as well, but I have no such intentions. Yoav ___ IPsec mailing list IPsec@ietf.org
Re: [IPsec] P2P VPN - Side Meeting
Hi Mike On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote: Hi Yoav, Please see inline. Mike. On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We use other tunnel mechanisms (GRE), because IPsec tunneling mode is lacking in functionality. For example, when you use GRE for the tunneling you also reduce the IPsec SA's that are needed to describe the traffic for IPsec to encrypt. If you use IPsec tunnel mode only then for each pairing of subnets behind each peer you need a separate IPsec SA. For example if there are 5 subnets each behind two peers then you need up to 25 SA pairs to describe exactly what needs to be encrypted and nothing more. If you tunnel the data traffic first then you only need 1 SA pair for all traffic, since IPsec encrypts the tunnel itself and not the traffic within the tunnel. This was correct in IKEv1, but in IKEv2 you can have a bunch of ranges for each traffic selector. Regardless, it has long been a (undocumented) practice, by more than one vendor, to negotiate universal tunnels, so that a single IPsec SA can be used for all the traffic between two peers. What you call other fancy features is what I call functional separation. IPsec does encryption well, but in reality it does a fairly poor job of tunneling. So lets have IPsec do what it does well and have GRE do what it does well and that is tunneling. Then you add NHRP do to next-hop resolution, which is what it was specifically designed to do, so that you can dynamically find peers and dynamically build new GRE tunnels protected by IPsec. Note, NHRP runs through the GRE tunnel so the single IPsec SA, since it encrypts the tunnel, also protects NHRP. Finally you add a routing protocol to advertise the reachablity of subnets/networks through the tunnel. Again this all goes through tunnel so the single IPsec SA protects this traffic as well. Basically you now have a system where you are using the proper tool to do the job that it was designed to do and that it does best. If you were to to try to overload these functions back into IPsec/IKE then you would end up with a less efficient system. I agree that this is a solution, but I don't agree that this is necessarily the best solution. I'm also missing
Re: [IPsec] P2P VPN - Side Meeting UNCLASSIFIED
Classification:UNCLASSIFIED The problem with a single SA is that it usually means a single key (what ever form that takes) such that a compromise of a single spoke puts all traffic at risk... So what ever solution we go for - we need to keep one eye on the security requirements... Chris [This message has been sent by a mobile device] - Original Message - From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Tuesday, November 15, 2011 11:08 AM To: Mike Sullenberger m...@cisco.com Cc: ipsec@ietf.org ipsec@ietf.org; f...@cisco.com f...@cisco.com Subject: Re: [IPsec] P2P VPN - Side Meeting Hi Mike On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote: Hi Yoav, Please see inline. Mike. On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We use other tunnel mechanisms (GRE), because IPsec tunneling mode is lacking in functionality. For example, when you use GRE for the tunneling you also reduce the IPsec SA's that are needed to describe the traffic for IPsec to encrypt. If you use IPsec tunnel mode only then for each pairing of subnets behind each peer you need a separate IPsec SA. For example if there are 5 subnets each behind two peers then you need up to 25 SA pairs to describe exactly what needs to be encrypted and nothing more. If you tunnel the data traffic first then you only need 1 SA pair for all traffic, since IPsec encrypts the tunnel itself and not the traffic within the tunnel. This was correct in IKEv1, but in IKEv2 you can have a bunch of ranges for each traffic selector. Regardless, it has long been a (undocumented) practice, by more than one vendor, to negotiate universal tunnels, so that a single IPsec SA can be used for all the traffic between two peers. What you call other fancy features is what I call functional separation. IPsec does encryption well, but in reality it does a fairly poor job of tunneling. So lets have IPsec do what it does well and have GRE do what it does well and that is tunneling. Then you add NHRP do to next-hop resolution, which is what it was specifically designed to do, so that you can dynamically find peers and dynamically build new GRE tunnels protected by IPsec. Note, NHRP runs through the GRE tunnel so the single IPsec SA, since it
Re: [IPsec] P2P VPN - Side Meeting UNCLASSIFIED
On Nov 15, 2011, at 7:36 PM, Ulliott, Chris wrote: Classification:UNCLASSIFIED The problem with a single SA is that it usually means a single key (what ever form that takes) such that a compromise of a single spoke puts all traffic at risk... So what ever solution we go for - we need to keep one eye on the security requirements... Chris Hi Chris I don't mean a single SA for the whole configuration. I mean a single SA for every pair of gateways, rather than lots of SAs, one for each pair of subnets. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote: Mark == Mark Boltz mark.bo...@stonesoft.com writes: Mark With all due respect to Cisco, the larger problem we're trying Mark to address, is in part the fact that DMVPN and ACVPN are Mark vendor specific implementations. And the goal of the Mark implementation we're seeking is *large scale* P2P VPNs. Assume that they are available on a wide variety of platforms, what is broken in the technology? I don't know, but I've been told that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard (and please someone correct me if I'm wrong) that they don't interoperate. So the tools are apparently not enough. Mark Picture a hypothetical where a larger interest desires an Mark IPsec VPN, in, say the airline industry. We're talking about Mark several thousand aircraft from several manufacturers. All in We've been through all of this 15 years ago with AIAG's ANX. You really want to tout that experience as a success story? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Couple of clarification here. Juniper implementation of AC-VPN does not do GRE over IPSec. It is IPSec alone for implementation (Route based VPN). Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN there are proprietary messages. It uses standard messages, but has many proprietary payloads. We believe NHRP is *necessary* but not *sufficient*. Also the way Hub download PAD/SPD to spokes (so that they can talk to each other directly) is not standard. We believe, there is a requirement for standard so that we can interop with other vendors. -- Praveen On 11/15/11 7:26 AM, Yoav Nir y...@checkpoint.com wrote: On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote: Mark == Mark Boltz mark.bo...@stonesoft.com writes: Mark With all due respect to Cisco, the larger problem we're trying Mark to address, is in part the fact that DMVPN and ACVPN are Mark vendor specific implementations. And the goal of the Mark implementation we're seeking is *large scale* P2P VPNs. Assume that they are available on a wide variety of platforms, what is broken in the technology? I don't know, but I've been told that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard (and please someone correct me if I'm wrong) that they don't interoperate. So the tools are apparently not enough. Mark Picture a hypothetical where a larger interest desires an Mark IPsec VPN, in, say the airline industry. We're talking about Mark several thousand aircraft from several manufacturers. All in We've been through all of this 15 years ago with AIAG's ANX. You really want to tout that experience as a success story? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
On 16 Nov 2011, at 01:57, Praveen Sathyanarayan wrote: Couple of clarification here. Juniper implementation of AC-VPN does not do GRE over IPSec. It is IPSec alone for implementation (Route based VPN). Yes, AC-VPN uses NHRP to do resolution just like DM-VPN. But in AC-VPN there are proprietary messages. It uses standard messages, but has many proprietary payloads. We believe NHRP is *necessary* but not *sufficient*. Also the way Hub download PAD/SPD to spokes (so that they can talk to each other directly) is not standard. thank you for clarifying! We believe, there is a requirement for standard so that we can interop with other vendors. I think I can agree with that. fred -- Praveen On 11/15/11 7:26 AM, Yoav Nir y...@checkpoint.com wrote: On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote: Mark == Mark Boltz mark.bo...@stonesoft.com writes: Mark With all due respect to Cisco, the larger problem we're trying Mark to address, is in part the fact that DMVPN and ACVPN are Mark vendor specific implementations. And the goal of the Mark implementation we're seeking is *large scale* P2P VPNs. Assume that they are available on a wide variety of platforms, what is broken in the technology? I don't know, but I've been told that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard (and please someone correct me if I'm wrong) that they don't interoperate. So the tools are apparently not enough. Mark Picture a hypothetical where a larger interest desires an Mark IPsec VPN, in, say the airline industry. We're talking about Mark several thousand aircraft from several manufacturers. All in We've been through all of this 15 years ago with AIAG's ANX. You really want to tout that experience as a success story? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Mike == Mike Sullenberger m...@cisco.com writes: Mike We use other tunnel mechanisms (GRE), because IPsec tunneling mode Mike is lacking in functionality. For example, when you use GRE for the Mike tunneling you also reduce the IPsec SA's that are needed to Mike describe Mike the traffic for IPsec to encrypt. If you use IPsec tunnel mode only Mike then for each pairing of subnets behind each peer you need a separate Mike IPsec SA. For example if there are 5 subnets each behind two peers Mike then you need up to 25 SA pairs to describe exactly what needs to be Mike encrypted and nothing more. If you tunnel the data traffic first Mike then Mike you only need 1 SA pair for all traffic, since IPsec encrypts the Mike tunnel itself and not the traffic within the tunnel. So, you trade IPsec SAs (security ACLs) for extended access-lists and routing tables. I don't see a difference if both are automatically updated by a policy engine. I can see that this might matter for devices with fixed purpose ASICs that accelerate one kind of access list, but not another.. I am not sure where you are getting a set of extended access-lists. There aren't any extended access-lists added. If a packet is routed through the tunnel it is encapsulated and then encrypted. There isn't any access-list necessary. As for routing table, you have that in either case. With pure IPsec you don't run a routing protocol over the tunnel but the peer (hub at least) still needs to advertise what subnets are reachable through the VPN, especially in cases where you have alternate paths to get to the remote network. Mike What you call other fancy features is what I call functional Mike separation. Mike IPsec does encryption well, but in reality it does a fairly Mike poor job of Mike tunneling. So lets have IPsec do what it does well and have Mike GRE do what Mike it does well and that is tunneling. Then you add NHRP do to Mike next-hop I'm curious if you've worked with any other vendor's IPsec? Because the issues you describe seem to be implementation limitations. I have worked some with other vendor's IPsec when troubleshooting interaction issues. I still believe that IPsec at the base is not a good tunneling protocol. Still, I think that NHRP over GRE is a pretty good solution to the problem, particularily if in the end, you didn't want to actually have any ACLs on the resulting tunnels. Mike. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ++ | Mike Sullenberger; DSE | | m...@cisco.com.:|:.:|:. | | Customer Advocacy CISCO | ++ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On 15 Nov 2011, at 23:03, Michael Richardson wrote: [...] So, you trade IPsec SAs (security ACLs) for extended access-lists and routing tables. I don't see a difference if both are automatically updated by a policy engine. I can see that this might matter for devices with fixed purpose ASICs that accelerate one kind of access list, but not another.. The net effect is the number of negotiations is greatly reduced when there are many prefixes in play. [...] I'm curious if you've worked with any other vendor's IPsec? Because the issues you describe seem to be implementation limitations. we actually do have both types of implementations. In practice, we find IPsec + tunneling largely superior. Less negotiations, easier to troubleshoot and scale. The peer discovery issue is really is an overlay / transport (network virtualization) problem that is well solved outside of IPsec and tunnels just made sense. thanks, fred Still, I think that NHRP over GRE is a pretty good solution to the problem, particularily if in the end, you didn't want to actually have any ACLs on the resulting tunnels. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With modern ipsec tunneling (got to love that), there is still a lot of negotiation going on. We are talking about potentially hundreds of subnets behind a branch here. On 16 Nov 2011, at 10:51, Yoav Nir wrote: On Nov 16, 2011, at 9:32 AM, Tero Kivinen wrote: What you call other fancy features is what I call functional separation. IPsec does encryption well, but in reality it does a fairly poor job of tunneling. So lets have IPsec do what it does well and have GRE do what it does well and that is tunneling. So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). That means that your security policy is effectively determined by the routing protocol. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Mike Sullenberger writes: I conceed the 1 IPsec SA issue, but with IPsec you still have to enumerate all of the subnets within that SA and renegotiate when subnets are added or removed. With GRE tunneling IPsec only ever sees the GRE tunnel packet I most likely would need to read the draft to understand more correctly what subnets you are talking about. My understanding from the discussion on the list was that we wanted to connect multiple spokes connected to hubs to each other directly wihtout going through the hub. I understood that the subnets negotiated would be those between those two spoke systems, and they are usually quite stable, meaning there will be new subnets added only every few days/weeks/months, not every hour, thus the rekeying interval will be more frequent than the renegotation because of the changes in subnet lists. I might be wrong, as I have just tried to understand what people are doing by reading the discussion on the list... So you still didn't explain what GRE does better than modern IPsec tunneling? GRE is multiprotocol, an example is that I can run MPLS label switching directly over GRE and then encrypt the GRE/IP packet, whereas I cannot run MPLS directly over IPsec. Ok, I assumed that we were still trying to be inside the IP-protocol stack and forward IP-packets. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Yoav Nir writes: So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). I.e. bypass the security mechanishms provided the security protocol. That means that your security policy is effectively determined by the routing protocol. I.e. move the security from the security protocol to something else which is not a security protocol. Is this really something we want to do? Who is going to make sure the end result is secure? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Frederic Detienne writes: And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With modern ipsec tunneling (got to love that), there is still a lot of negotiation going on. I do not understand what you are trying to say there. We are talking about potentially hundreds of subnets behind a branch here. Really? There must be something really, really wrong in their IP-address allocation in that case. Usually the one branch has only few subnets as it would make adminstration really hard if you put hundreds of separate subnets in the same branch office. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On 16 Nov 2011, at 13:48, Tero Kivinen wrote: Frederic Detienne writes: And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With modern ipsec tunneling (got to love that), there is still a lot of negotiation going on. I do not understand what you are trying to say there. even with modern ipsec tunneling, one selector has to be negotiated for each pair of prefixes to protect. This can amount to a lot of selectors to negotiate in practice. We are talking about potentially hundreds of subnets behind a branch here. Really? There must be something really, really wrong in their IP-address allocation in that case. Usually the one branch has only few subnets as it would make adminstration really hard if you put hundreds of separate subnets in the same branch office. Really and there is nothing wrong. It is your view that these are branch offices. A spoke is only a branch from a topology standpoint but the actual spoke device may protect a very large networks at very high throughput. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Security is a matter of architecture and end-to-end design. Several mechanisms are used to achieve an efficient balance with complexity. Features and security protocols are only building blocks. IPsec and IKE are not the only features that protect a network and routing as a security policy really is not a problem until shown otherwise. Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. On 16 Nov 2011, at 14:17, Yoav Nir wrote: On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: Yoav Nir writes: So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). I.e. bypass the security mechanishms provided the security protocol. Yes! That means that your security policy is effectively determined by the routing protocol. I.e. move the security from the security protocol to something else which is not a security protocol. Is this really something we want to do? Define we Who is going to make sure the end result is secure? The customer ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Frederic Detienne writes: Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. When one does not know what problem we are really solving and what security and other requirements that problem has, it is very hard to be specific about anything. On the other hand when some comments related to the problems that were fixed more than 5 years ago (and that work was started EXACTLY 10 years ago), so that does affect my feeling on the issue. Btw. draft-ietf-ikev2-00 was published 2001-11-16 -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
OK. Routing protocols are not security protocols. That's fine. Neither is HTTP. BGPSEC and SIDR implement a layer of security on top of BGP to overcome this issue, and that may be used in the Internet. OSPF and NHRP are designed to be used in closed environments (corporate networks), where everyone is assumed to be playing nice, so there has never been as much requirement for a security layer, and in fact there is no security layer to NHRP. When you extend NHRP to an overlay network over the Internet, as you do with GRE, you are still fine as long as everybody plays nice. With the obvious example of a corporate network with tunnels to the branches in New York, London, Paris, and Shang-hai you're still fine, because all the gateways are configured by the same person or organization, or at least they are part of the same hierarchy, although by this point you may need to be worried about misconfiguration. With a multiple-administrative-domain use case, all bets are off. What would prevent a gateway anywhere from claiming responsibility for the addresses of the facebook.com server? That would cause several bad things: - that gateway gets access to all facebook traffic in the entire overlay network - all the gateways have to work extra hard encrypting facebook content for no reason at all. This is a real problem regardless of whether we use IPsec tunnels or GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever solution we pick (as a working group) we will still need to develop a security layer, which may or may not be based on what the BGP people are doing. This is especially important for cross-domain use cases, but would be very helpful for same-domain as well. Yoav On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote: Security is a matter of architecture and end-to-end design. Several mechanisms are used to achieve an efficient balance with complexity. Features and security protocols are only building blocks. IPsec and IKE are not the only features that protect a network and routing as a security policy really is not a problem until shown otherwise. Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. On 16 Nov 2011, at 14:17, Yoav Nir wrote: On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: Yoav Nir writes: So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). I.e. bypass the security mechanishms provided the security protocol. Yes! That means that your security policy is effectively determined by the routing protocol. I.e. move the security from the security protocol to something else which is not a security protocol. Is this really something we want to do? Define we Who is going to make sure the end result is secure? The customer Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On Nov 16, 2011, at 3:31 PM, Tero Kivinen wrote: Frederic Detienne writes: Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. When one does not know what problem we are really solving and what security and other requirements that problem has, it is very hard to be specific about anything. On the other hand when some comments related to the problems that were fixed more than 5 years ago (and that work was started EXACTLY 10 years ago), so that does affect my feeling on the issue. Btw. draft-ietf-ikev2-00 was published 2001-11-16 draft-ietf-ipsec-ikev2-00 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On Nov 16, 2011, at 3:38 PM, Tero Kivinen wrote: Frederic Detienne writes: Frederic Detienne writes: And like I said earlier, the amount of negotiation when there are multiple prefixes to protect is limited to one. With modern ipsec tunneling (got to love that), there is still a lot of negotiation going on. I do not understand what you are trying to say there. even with modern ipsec tunneling, one selector has to be negotiated for each pair of prefixes to protect. This can amount to a lot of selectors to negotiate in practice. Not for each pairs of prefixes, but for one selector for each subnet in total. I.e. if one end has 10 subnets and another has 100, then you need 10 initiator traffic selectors and 100 responder traffic selectors. You could even negotiate universal selectors (0.0.0.0-255.255.255.255) and then use some other source of policy (for example: the subnet attribute in the configuration payload). I think that is what Microsoft's IKEv2 clients do, but it has been over a year since I looked at it, so I may be wrong. We could document an any selector. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
