What you are referring to is when a single SA/key is shared across multiple
devices (or the entire network). Here, we are talking about a unique SA pair
between any two devices. I.e. each device pair on the network has its own IPsec
SA.
fred
On 15 Nov 2011, at 19:36, 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
>
> [This message has been sent by a mobile device]
>
> ----- Original Message -----
> From: Yoav Nir [mailto:[email protected]]
> Sent: Tuesday, November 15, 2011 11:08 AM
> To: Mike Sullenberger <[email protected]>
> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>
> 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
> [email protected]
> 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 [email protected].
>
> 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
> [email protected]
>
> ****************************************************************************
>
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
