[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed changes to ISAKMP/Oakley
Harald,
>>
>> The link gets the packets there, but does your policy actually allow
>> you to do anything with them?
>
>In my case, yes. We have a fairly sophisticated policy engine for deciding
>what 'group' traffic belongs to, and allowing proxying and/or forwarding of
>packets. One of the group selectors is the SA used to auth/decrypt a packet.
>
>But that's irrelevant; my issue is that I don't want to be required to
>negotiate a separate SA for each pair of networks (or worse, pair of hosts)
>on opposites sides of a "tunnel". That way lies resource exhaustion. But it
>appears that many people want to *require* this as part of their policy
>engines.
>
>I agree; this is something that will be worked out in the VPN work.
What I proposed for inbound processing does not require a separate SA per
network pair. It requires that the receiver check the inbound packets
against the set of selectors used to map traffic to the SA in question.
So, if one maps traffic for a range of IP addresses to a single SA, one
checks to make sure that the packets emitted from that SA contain an IP
source address consistent with the selector set. This is not just a VPN
issue, the same concerns apply to host SAs.
Steve
Follow-Ups:
References: