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 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 how trust is established, and how advertising the reachability can be made secure. As long as you don't have tunneling, a router can only lie to its neighbors, and even that problem was severe enough that the SIDR group was set up to solve it. Once you add tunneling, those lies can propagate all around the world. So within the large overlay network, you either have to assume that everyone "plays nice", or else you need some security mechanism to secure these advertisements. To my mind, the security part of this is the real challenge, regardless of whether we model IPsec tunnels as links or not. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmas...@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email info...@gchq.gsi.gov.uk **************************************************************************** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
