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, PasiThanks for clarifying the "clarification." I was worried by the suggestion that sending this attribute via IKE caused a change to the SPD.Steve
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 4.4.2.2 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.
Yoav _______________________________________________ Ipsec mailing list Ipsec@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ipsec