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

Re: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD

On Jun 28, 2006, at 7:11 PM, Stephen Kent wrote:

At 6:22 PM +0300 6/28/06, <Pasi.Eronen@xxxxxxxxx> wrote:
It's good to note that the INTERNAL_IP*_SUBNET attributes do not
necessarily affect the SPD at all. They contain the gateway's policy
about what traffic it would like to see sent via this tunnel... but
unless the client trusts the gateway unconditionally, it should not
change its SPD based on the information.

But I guess you were considering the case where the client does
trust the information to be correct. I'd say that in most cases
it does not really change the SPD, but rather the routing table
(and thus source address selection). Traffic that is sent via the
tunnel uses the IP address assigned by the gateway as the source
address; traffic that should bypass the tunnel most likely would
use the IP address assigned by the local DHCP server.

Best regards,

Thanks for clarifying the "clarification." I was worried by the suggestion that sending this attribute via IKE caused a change to the SPD.


I'm not sure you can avoid it.

Since the client does not have the IP address assigned through the Configuration payload, we either have no triggering packet, or we use a source IP address of like in DHCP.

Suppose the SPD entry has ANY for the local address and ANY for the remote addresses (what else can it have) The relationships described in section of RFC 4301 do not describe a way to get from "Any" to a list of ranges on either side, and the values on the triggering packet are no help either. The SA that was created has a single assigned IP address as the local, and a list of ranges as the remote.

I don't see how we can make the client policy fit the model in RFC 4301 unless we allow a temporary change in the SPD.


Ipsec mailing list