[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD
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.
> -----Original Message-----
> From: ext Yoav Nir [mailto:ynir@xxxxxxxxxxxxxx]
> Sent: 28 June, 2006 14:00
> To: ipsec@xxxxxxxx
> Subject: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD
> Steve Kent's reply about the secure beacon document, prompted me to
> look at the description of the INTERNAL_IP*_SUBNET attributes in RFC
> 4306 and the clarifications draft.
> The attributes in the Configuration payload are used by the IKE
> responder (call it a gateway) to tell the IKE initiator (call it a
> client) what addresses it protects.
> My question is, how does this affect the SPD on the client?
> I have two possible answers in mind:
> 1. The client begins with an empty SPD (or maybe one entry that says
> BYPASS everything). It forces IKE, and then when it learns what
> subnets are protected, it adds PROTECT SPD entries that match the
> subnets described in the Configuration payload.
> 2. The client begins with a PROTECT entry for everything. When it
> receives the Configuration payload, it replaces that entry with more
> granular entries.
> Which (if any) do you think is correct?
Ipsec mailing list