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

[<Pasi.Eronen@xxxxxxxxx>]

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,
Pasi


> -----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
> 
> Hi.
> 
> 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?
> 
> Yoav

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec