[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.
Thanks for clarifying the "clarification." I was worried by the
suggestion that sending this attribute via IKE caused a change to
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 0.0.0.0 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 184.108.40.206 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
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