[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No Subject

Joern,


>At 11:43 19/01/99 -0800, you wrote:
>>
>>Hi,
>>
>>I ran into an interoperability situation between 2 ipsec implementations
>>when the
>>customer tried to set up 2 networks behind a security gateway as part of the
>>same vpn.
>>
>>network1 -----
>>                    |
>>                   SG1----x             x--SG2--- peer network
>>                    |
>>networks -----
>>
>
>In a QM negotiation, you use IDs to specify the networks that are
>supposed to talk to each other. That could be
>192.168.1.0/24 (behind SG1) and 192.168.2.0/24 (behind SG2).
>I would be very surprised if the resulting SA was used for something else
>than traffic between these networks.
>
>If SG1 really sends data from 192.168.3.0/24 through that SA,
>I'd say that this implementation is faulty.
>
>You need several SAs here. And if each SG has 10 subnets, there will
>be 100 SAs. A possible workaround would be to do QM with 0.0.0.0/0
>IDs and some policy-based filtering.
>
>If you want the most interoperable approach:
>When sending packets, mind the QM IDs used to create the SA.
>When receiving packets, you could invent a policy setting to
>allow traffic that does not match the IDs. You could. I don't
>say that you should.

One needs to establish an SA at the granularity of each subnet, if one
cannot aggregate the subnet addresses under the IPaddress range feature
allowed in IKE and in the SPD definition.  The SPD originally allowed for a
set of disjoint addresses as a selector, but since IKE does not support
that negotiation, we dropped the facility in later versions. The IPsec
architecture requires a receiver to check any header fields that are used
as selectors for an SA, so an implementation in which a receiver did not do
so would not be compliant with RFC 2401.

Steve
References: