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

Re:

Sankar,
In your example, both sides have a common security policy, but when a SA
is negotiated, it is done for a single pair of networks (say, network 1
and 'peer network').  So, the IPSec SA is infact, enforcing a
restrictive policy than what you have configured.  Going by the 'be
conservative in what you accept' approach, you would want to verify that
the packets received over a SA are infact packets from the networks for
which the SA was negotiated.  As far as the Security Arch. RFC goes, an
implementation is supposed to verify that a packet received over a SA is
actually allowed to use that SA.  Considering all of the above, I'd say
that SG2's behavior is correct.

Short of using vendor payloads, I can't think of a way to negotiate
multiple, disjoint networks using IKE.  You'd probably be safe
negotiating one SA per network pair that you want to protect.  Yes, it
creates an explosion of SAs should your VPN consist of many networks at
the two ends.  However, if you are using manual SAs, I don't see why you
couldn't have one SA for your entire VPN.

If I remember right, the last time this discussion came up, it was
decided that this was an IPSecond issue.

Sumit A. Vakil
Internet Devices, Inc.

Sankar Ramamoorthi 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 the first implementation (SG1)
>     The security gateway uses the same ipsec SA to send traffic from both
> networks
>     since data originating from both the networks are part of the same VPN
> and hence
>     there is no point creating another SA with the same crypto parameters.
> The security
>     gateway applies the same logic on inbound traffic also and accepts
> packets on an
>     ipsec SA as long as the ip addresses match local policy.
> 
> In the second implementation (SG2)
>     The implemenation is more stringent and tries to constrict the packets
>     accepted on an SA to exactly match the addresses negotiated for that SA.
> The drawback of this
>     approach seems to that when one want to protect more than one network as
> part of the
>     same VPN (policy) you have to create 1 SA per network. The same problem
> exists
>     when you want hosts from more than one network to be part of the same
> VPN (policy).
>     You incur the cost of creating multiple SAs.
> 
>     Both SG1 and SG2 agree on local policy. However SG1 creates only one SA
> where as
>     SG2 expects multiple SAs to be created. SG2 requires ip addresses of
> decrypted packets
>     on SA to match the negotiated addresses. This forces SG1 to create
> multiple SAs. SG1 also
>     verifies the addresses of decrypted packets but they are accepted as
> long as the match
>     the local policy.
> 
>    Should the address checking be local policy based or based on negotiated
> addresses?
>    The additional SAs share the same crypto parameters and hence seem
> reduntant.
> 
>     I reviewed the archives. There were previous discussions on this topic
> but never any
>     definite conclusion. The RFCs does not take a position one way or other.
> 
>     I am willing to go either way but would like to know the most
> interoperable approach.
>     My preferance is to avoid creating multiple SAs in this scenario unless
> there is a defnite
>     security advantage/reason for constricting ipsec SAs created for the
> same VPN (policy).
> 
>     Thanks for any comments.
> 
>     -- sankar (sankar@vpnet.com) --
References: